Un framework web pour Go ?

a marqué ce sujet comme résolu.
Auteur du sujet

Salut !

Je cherche sans succès un framework web complet comme Laravel, Symfony pour GoLang mais je ne trouve que des framework spécialisé dans les API …

Des bon framework en Go à me proposé ?

Github | Le succès est un mauvais professeur. Il pousse les gens intelligents à croire qu’ils sont infaillibles. - Bill Gates

+0 -0

Salut, je connais Revel (je l’avais testé rapidement, donc je ne sais plus trop ce qu’il vaut): https://revel.github.io/

Sinon pour mon dernier projet, j’ai utilisé go-macaron couplé à gorm pour la base de données. Le seul soucis, c’est que ce n’est pas très complet comme framework, et à comparer de Laravel ou Symphoni, il y a beaucoup de chose à faire à la main (les migrations notamment).

Si quelqu’un à quelques chose de mieux, je suis aussi preneur. C’est dommage de ne pas avoir quelque chose d’aussi complet que Laravel en Go.

+0 -0

Cette réponse a aidé l’auteur du sujet

Buffalo correspond bien.

Je l’ai déjà utilisé une ou deux fois, ça marche bien.

Après, question d’approche, mais il faut bien voir que "framework" est presque un gros mot dans la culture des gophers. Buffalo a pour but d’offrir une porte d’entrée facile à franchir, mais plusieurs toutes petites choses peuvent éventuellement en détourner les gens. Notamment :

  • Il n’utilise pas gorm (l’ORM le plus populaire en Go), mais un autre ORM custom : pop. En soi, ce n’est pas un gros problème à l’utilisation parce que pop est très bien, qu’il s’intègre parfaitement avec les autres outils de buffalo, tout en laissant pas mal de hooks disponibles pour customiser le comportement des modèles auto-générés.
  • Les handlers ne suivent pas l’interface du package standard net/http, contrairement à toutes les autres bibliothèques de l’écosystème de Go. Ça aussi, en soi, ce n’est pas très grave, mais il faut le savoir : quand on écrit un handler avec Buffalo, ce n’est pas un http.HandlerFunc standard. Cela dit, les abstractions fournies par Buffalo pour ce design valent le coup. Il faut donc se poser la question de savoir si la compatibilité entre les handlers qu’on écrit avec Buffalo et un http.Server standard est importante ou non à nos yeux (souvent, non, mais il faut quand même se poser la question).
  • Les migrations ne s’écrivent pas directement en SQL, mais plutôt dans un langage custom (fizz). Ça non plus, en soi ce n’est pas un gros soucis, d’autant plus que quand on crée un nouveau modèle, les fichiers de migration sont automatiquement générés.

Après, se pose la question de savoir si le fait d’auto-générer ses modèles et ses migrations constitue un réel apport à l’échelle du projet. Et surtout quelle est l’ambition de celui-ci. En ce qui me concerne, j’ai une approche "anti-framework", parce qu’à l’échelle de mon projet, le temps que je passe à écrire des migrations en SQL et des modèles pour gORM est négligeable devant le temps que je passe sur le reste de mon travail : je n’ai pas besoin de définir des modèles tous les jours, et seulement une partie de mon backend repose sur un SGBDR. Si jamais cette tendance venait à s’inverser demain, l’approche "go" voudrait que j’écrive moi-même mon générateur de code, adapté à ma stack, et je le ferais sans hésiter… Mais ça, c’est mon point de vue dans le contexte de mon projet : si demain j’étais amené à travailler sur un projet de site web classique, je pense que Buffalo est probablement le choix que je ferais, et je sais déjà qu’il me ferait gagner un paquet de temps.

Édité par nohar

I was a llama before it was cool

+2 -0
Auteur du sujet

Merci pour ton message explicatif cependant après avoir vu la documentation de Buffalo, j’ai l’impression qu’il n’est plus maintenu ?

Github | Le succès est un mauvais professeur. Il pousse les gens intelligents à croire qu’ils sont infaillibles. - Bill Gates

+0 -0

Cette réponse a aidé l’auteur du sujet

La dernière release datant de 15 jours me fait dire que si…

Tu es sûr que tu ne confonds pas avec le message disant qu’il arrêtent de supporter les méthodes d’installation obsolètes (GOPATH) en faveur des go modules qui sont la méthode standard depuis Go 1.11, et qu’ils arrêtent d’ailleurs de supporter les versions de Go antérieures à 1.13 ?

C’est plutôt un signe qu’ils comptent maintenir et faire évoluer Buffalo pendant encore un bon moment, au contraire. :D

Édité par nohar

I was a llama before it was cool

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte