Home Artigos Web apps em Go?

Web apps em Go?

0
0
652

Go vem despontando, gradualmente, no universo das aplicações web. E existem muitas vantagens sobre outras linguagens às quais devemos considerar.
Os programas escritos em Go são binários que são executados de forma nativa, portanto, não há necessidade de nenhum intermediário instalado no servidor, como é o caso da máquina virtual do Java, por exemplo, não há tempo de execução separado, é tudo parte do binário. Programas em Go podem fácil e elegantemente executar tarefas em segundo plano, assim não há necessidade de ferramentas como Resque. Programas escritos em Go rodam como um único processo, o que torna o armazenamento em cache desnecessário. Go consegue lidar com um número ilimitado de conexões paralelas. Toda aquela pilha de apps necessários para uma aplicação web se reduz a apenas um binário. O único outro componente necessário é um banco de dados.

O boot de um programa em Go provavelmente superará qualquer aplicação em Python / Ruby em questão de desempenho, pois requer menos memória além de menos linhas de código.

Existe algum framework popular para Go?

A resposta simples é: um framework é totalmente opcional e não recomendado. Existem muitos projetos que se dizem excelentes frameworks, mas acredito que o melhor caminho é desenvolver sem um. E olha que esta não é apenas a minha opinião pessoal, é geralmente compartilhada na comunidade Go.

Isso nos leva a pensar por que os frameworks surgiram, em primeiro lugar. Falando de Python / Ruby, foi porque essas linguagens não foram inicialmente projetadas para servir páginas da web e muitos componentes externos eram necessários para cumprir tal tarefa. O mesmo pode ser dito para Java, que, assim como Python e Ruby, é quase tão antigo quanto a web como a conhecemos, ou até mesmo um pouco mais antigo.

As primeiras versões do Python “out of the box” não forneciam nada para se comunicar com um banco de dados, não havia uso de template, o suporte HTTP era confuso, comunicação em rede não era trivial, empacotamento de criptografia não seria nem legal, em termos de leis, e havia um monte de outras coisas faltando. Um framework forneceu todas as peças necessárias e estabeleceu regras para o desenvolvimento idiomático para todos os cases comuns de uso de aplicativos web.

Go, por outro lado, foi construído por pessoas que já experimentaram e compreenderam o desenvolvimento web. Inclui quase tudo o que é necessário. Um ou dois pacotes externos podem ser necessários para lidar com certos aspectos específicos, como OAuth, mas de nenhuma maneira um ou dois pacotes constituem um “framework”.

Se o o que foi dito acima sobre frameworks não for convincente o suficiente, é útil considerar a curva de aprendizagem dos frameworks e os riscos. Levou-me cerca de dois anos para me sentir confortável com Rails. Frameworks podem ser abandonados a qualquer momento e tornarem-se obsoletos. Migrar aplicativos para um novo framework é difícil, se não impossível. Dada a rapidez com que as tecnologias da informação mudam, os frameworks não devem ser escolhidos em vão.

Uma observação sobre ferramentas e frameworks que tentam imitar a linguagem comum aos ambientes Python, Ruby ou JavaScript. Qualquer coisa que se parece ou afirma ser “Rails for Go”, fornece técnicas como injeção, publicação de métodos dinâmicos e similares que exigem depender fortemente de reflexão, não são a maneira Go de fazer as coisas, é melhor se afastar delas.

Frameworks de fato tornam algumas tarefas mais fáceis, especialmente no típico mundo das aplicações CRUD, onde os aplicativos têm muitas telas com muitos campos, manipulando dados em esquemas de banco de dados complexos e em constante mudança. Em tais ambientes, eu não tenho nem certeza se Go é uma boa escolha, especialmente se o desempenho e escalonamento não são prioridade.

Outra questão comum aos frameworks é que eles abstraem mecanismos de baixo nível do desenvolvedor, frequentemente de tal forma que ao longo do tempo se tornam tão arcanos que é literalmente impossível descobrir o que realmente está acontecendo. O que começa com um alias idiomático para uma única linha de JavaScript tornam-se camadas sobre camadas de transpilers, minimizers rodando sobre helpers ocultos em algum lugar de alguma  subdependência. Daí um belo dia algo quebra, e vai quebrar,  e é praticamente impossível saber por onde procurar o problema. Às vezes, somente às vezes, é bacana saber exatamente o que está acontecendo, bem, Go é geralmente muito bom nisso.

Sobre banco de dados e ORM:

Da mesma forma que os frameworks, o mundo Go não é grande fã de ORM’s. Para iniciantes, Go especificamente não suporta objetos, que é o que o “O” em ORM significa (Object-Relational Mapping).

Sabemos que escrever SQL na unha em vez de depender de User.find (: all) .filter …  – conveniência fornecida pelos prazeres do ActiveRecord – é algo novo em algumas comunidades, mas acho que essa atitude precisa mudar. SQL é uma linguagem incrível. Lidar com SQL diretamente não é tão difícil, e até bastante libertador, bem como incrivelmente poderoso.

Conclusão:

Eu acho que isso descreve bem a situação atual do back-end. O front-end eu acho que poderia ser um post separado. E será.

Referência: https://grisha.org/blog/2017/04/27/simplistic-go-web-app

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Veja Também

Validação de CPF e CNPJ em Go

Simples e direto. Funções para validar CPF e CNPJ em Go. …