Qualquer hype é muito engraçado quando você olha de lado. Menos engraçado quando você se envolve diretamente nele.
O Hype Go caiu em algum lugar em 2014, quando os autores de aplicativos que tinham 1000 RPM (solicitações por minuto) decidiram repentinamente que precisavam urgentemente de simultaneidade, porque seus 1000 RPM estavam prestes a se transformar em 1000 RPS (o que também não é muito, de fato).
O resultado do hype foi que muitas pessoas que se acostumaram à arquitetura MVC do aplicativo aderiram ao Go, seja Spring, Django ou Ruby on Rails. E essa arquitetura, como uma coruja em um globo, eles começaram a puxar Go. Então os cadáveres apareceram como Beego e
Revel . Revel morreu em segurança, embora eles ainda estejam tentando dar o fora. Mas eu quero falar sobre o Beego separadamente.
Richard Eng fez uma contribuição significativa para promover o Beego entre as massas com sua série de artigos
"Uma palavra, o Beegoist" . Praticamente o "Evangelho de Richard". Ironicamente, apesar do fato de Richard estar promovendo freneticamente o Go, ele próprio não escreve sobre ele.
Por sua vez, trabalhei com o Go e, pior ainda, com o Beego, trabalhei muito. E posso dizer que esse claramente não é o caminho que o desenvolvimento do Go deve seguir.
Vejamos alguns aspectos básicos do Beego e por que eles contradizem várias práticas recomendadas no Go e no setor como um todo.
Estrutura de pastas
Robert C. Martin, mais conhecido como
tio Bob , expressou repetidamente a idéia de que a estrutura de um aplicativo deve transmitir sua essência. Ele gosta muito de dar um exemplo com uma catedral, que pode ser vista de cima, e imediatamente entender que é uma catedral.
Robert criticou repetidamente o Ruby on Rails por sua estrutura de pastas - controladores, modelos, visualizações, isso é tudo. O problema dessa abordagem é que o aplicativo de meias mais vendido será exatamente como um aplicativo de pedidos de alimentos. E para entender a essência do aplicativo, você precisará subir na pasta de alguns modelos e ver com que tipo de entidades terminamos.
É esse comportamento doentio do Beego que se replica. Enquanto o mesmo Spring mudou para o Design Orientado a Domínio e a essência da estrutura de pastas, o Beego está forçando o uso de uma estrutura que se tornou antipadrão.
Mas o problema é ainda mais sério. Para o Go, não há separação entre a estrutura da pasta e a estrutura do pacote. Portanto, no Beego e UsersController e OrdersController estará sob um pacote - controladores. E se você tem dois tipos de controladores, aqueles que atendem à interface do usuário e aqueles que são usados para a API, além disso, em uma sociedade decente, eles geralmente são versionados? Então prepare-se para malucos como o apiv1.
ORM
Estranhamente, o Beego, sendo um clone do Ruby on Rails sem êxito, não usa o padrão ActiveRecord. Sua ORM é uma visão extremamente estranha. Se para operações completamente básicas, como ler uma linha / escrever uma linha, ainda é adequado, por exemplo, parece uma amostra simples (daqui em diante, exemplos são retirados diretamente da documentação):
qs.Filter("profile__age__gte", 18)
Mas o principal problema do Beego ORM não é que você precise lidar com o idioma proprietário, mas que ele usa todas as piores práticas de Go, sejam os efeitos colaterais da importação:
import ( _ "github.com/go-sql-driver/mysql" _ "github.com/lib/pq" _ "github.com/mattn/go-sqlite3" )
Ou registrando modelos em init ():
func init(){ orm.RegisterModel(new(User)) }
Faça um favor a si mesmo, mesmo se você ainda decidir por algum motivo inexplicável trabalhar com o Beego, não use o Beego ORM. Se sua vida sem ORM não é agradável (e o que você está fazendo no mundo de Go, querida?), Use
GORM . É pelo menos suportado. Caso contrário,
"database / sql" irá ajudá-lo.
Ferramenta abelha
A ferramenta de linha de comando, chamada simplesmente
Bee , é copiada do Ruby on Rails. Mas somente se no mundo do RoR havia trilhos e era ancinho, a abelha é um lixo para tudo. Ele e o aplicativo MVC para 'boostrap', executam a migração e o observador de arquivos será iniciado. Este último é outro problema. Afinal, qual é uma das principais vantagens do Go? O que começa localmente é o mais próximo possível do que começa na produção. Se você não usa abelha, é claro.
Roteamento automático
Go é uma linguagem de tipo forte que não suporta genéricos ou anotações. Como moldar uma estrutura MVC nisso? Lendo comentários e gerando arquivos, é claro.
Parece algo como isto:
A evidência, como você pode ver, é zero. A função Post () não recebe nem retorna nada. http.Request? Não, não ouvi.
Bem, como funciona todo o roteamento? Quando você inicia a notória abelha, outro arquivo é gerado, commentsRouter_controllers.go, que contém um exemplo desse código maravilhoso:
func init() { beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"] = append(beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"], beego.ControllerComments{ Method: "Post", Router: `/`, AllowHTTPMethods: []string{"post"}, MethodParams: param.Make(), Filters: nil, Params: nil}) ... }
Veja, não esqueça de gerar novamente e 'confirmar' esse arquivo após cada alteração. Até recentemente, a situação era ainda mais triste e, durante os testes, esse arquivo era gerado automaticamente, então você já aprendia sobre os problemas na produção. Parece que em versões recentes esse comportamento estranho foi corrigido.
Teste de componentes
E assim chegamos ao tópico dos testes. Ao contrário da maioria das outras linguagens de programação, o Go vem com uma estrutura de teste pronta para uso. Em geral, a filosofia do Go é que o teste fique ao lado do arquivo de teste. Mas estamos no mundo MVC, cuspimos na filosofia Go, certo? Portanto, seja gentil em colocar todos os seus testes no / test daddy, como o
DHH nos legou.
E isso não é tão trivial, porque, lembro-me, na pasta Go package ==. E se o teste localizado no mesmo pacote puder chamar o método privado, o teste localizado em outro pacote não estará mais lá.
Mas tudo bem, tudo seria limitado à estrutura da pasta. O código Beego é, em princípio, muito difícil de testar, porque tudo nele é um efeito colateral.
É assim que o Beego consulta roteadores:
import ( _ "github.com/../../routers" )
A mesma história com middlewares e com controladores que mencionei anteriormente.
A documentação
É como um arquiteto de software para mim em um bolo. A documentação do BeeGo é tão boa quanto o seu chinês. Não, os comentários em chinês dentro do código nos últimos dois anos se livraram.
Agora, em chinês, existem apenas alguns pedidos pull:
E especialmente em questões:
Em vez de uma conclusão
Se você possui uma equipe de gravadores de código Ruby / PHP / Python e deseja traduzi-los com urgência para o Go, a pior coisa a fazer é fazê-los mudar para a estrutura MVC no Go. O MVC como um todo é um padrão arquitetural mais ou menos, e no Go geralmente está fora de lugar. Ou, se tiver certeza absoluta de que nada, exceto o Go, salvará você, permita que eles reaprendam e escrevam da maneira como são aceitos no Go - o mais simples e explícito possível. Ou, talvez eles saibam melhor, com que ferramenta para resolver suas tarefas?