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é ?
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.
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 :
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). 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.
Merci pour ton message explicatif cependant après avoir vu la documentation de Buffalo, j’ai l’impression qu’il n’est plus maintenu ?
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. 
J’avais effectivement confondu ! Merci 
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