Breves relatos sobre minha experiência com Meteor

[felipeuntill]

TLDR;

Estou desenvolvendo uma plataforma delivery (SaaS) e decidi utilizar o framework Meteor como base para o projeto, um dos principais fatores que me fizeram optar pela ferramenta foi a facilidade em desenvolver aplicações reativas, todavia como tudo nesta vida tem seus pesares encontrei muita dificuldade para se adaptar ao modelo de desenvolvimento e decidi compartilhar com o grupo meu aprendizado.

Primeiras Experiências:

• 1- Inicialmente tentei trabalhar utilizando namespaces, porém como a sequência de loading do meteor é ordenada pelo nome dos arquivos e pastas, este tipo de solução passou a ser pouco efetiva uma vez que alguns elementos ainda não estavam disponíveis para eventualmente serem utilizados. Infelizmente o meteor não possui um modo de orquestrar o loading dos arquivos manualmente e a ideia de namespaces tive de ser abandonada.
• 2- Apesar de amar front-end sempre atuei desenvolvendo aplicações do lado servidor, portanto orientação a objetos e design patterns já fazem parte da minha vida a um bom tempo. Trabalhando com o meteor tive muita dificuldade em conseguir definir as responsabilidades de cada componente da aplicação, parte da minha lógica de negócios ficou nas rotas e parte no helpers, sem perceber eu estava passando por cima de todo o aprendizado que tive com orientação a objetos e trabalhando de forma totalmente desordenada.
• 3- Banco de dados, o meteor foi feito para andar junto com o nodejs, tentar trazer qualquer outro banco de dados para dentro da sua solução será uma tarefa complexa e exaustiva.

Considerando os problemas citados acima, só encontrei uma solução que foi trazer a robustez do desenvolvendo em linguagens fortemente tipadas para o javascript, decidi refatorar meu código e desenvolver novamente considerando todos os princípios do paradigma SOLID, uma vez que seguindo todos os princípios à risca você certamente terá uma aplicação testável, adaptável e de fácil manutenção.

Durante esta migração me deparei com os seguintes problemas:

Como o javascript não é tipado como definir meus contratos e interfaces?
R=> Tive de substituir o conceito de herança de interfaces pela herança de classes e para garantir que objetos possuem o escopo necessário efetuo uma comparação para saber se a implementação é derivada da classe esperada utilizando o recurso instanceof do ES6.

Como prover a inversão de controle?
R=> Não encontrei nada relacionado a inversão de controle que garantisse que a instância requisitada fosse realmente uma implementação da classe desejada, todas as referências que encontrei na internet eram apenas uma key value global que armazenava as informações para posterior consumo, tive de desenvolver um modulo para a gestão das dependências utilizando novamente as comparações de herança para evitar a implementação esteja errada, basicamente algo similar ao código abaixo;

    registarInstancia("implementacao", new InstanciaHerdadaImplementada())

E para obter a implementação e garantir que a respectiva atende aos meus requisitos:

    resolverInstancia("implementacao", IntanciaPaiSemDarNewParaComparar)

Se o objeto registrado no container não for derivado do segundo parâmetro retorno uma exceção.

Como remover a responsabilidade das rotas e helpers?
R=> Single Responsability se faz necessário sempre, então para conseguir seguir o meu plano à risca tive de estruturar minha aplicação do mesmo jeito que atuo com .Net/Java/Ruby criei para cada entidade do sistema criei suas respectivas classes (DTO), as classes de negócio(BO) e consecutivamente os serviços quais consolidam todas as informações para enviar aos helpers. Minhas rotas passaram a retornar somente os parâmetros assim como nas demais linguagens meus helpers apenas invocam serviços não havendo qualquer tipo de codificação complexa neste nível.

Como substituir os namespaces?
R=> Módulos são o que há, o meteor respeita os imports do ES6 e com isso minha aplicação deixou de ser tão Javascript e ficou realmente orientada a objetos.

Minhas observações sobre o Meteor

É um framework pratico, mas ao mesmo tempo exige que você realmente saiba programar porque você terá bem menos recursos comparado aos outros frameworks. Os pacotes do Atmosphere (npm do meteor) são totalmente largados e a maioria não possui manutenção, você até pode utilizar os pacotes do npm através de uns hacks mas não é nativo.
O framework é cheio de especificidades e isso exige muita adaptação, é muito diferente do que experimentei com express, koa e hapi e ainda estou receoso sobre quais limitações posso encontrar.

Em suma só recomendaria o framework para quem irá fazer forte uso de programação reativa em todos os demais casos express sem erro.

O modo como eu decidi desenvolver a aplicação foi totalmente pessoal, não sei até que ponto é correto trazer paradigmas de outras linguagens para dentro do javascript, em contrapartida também não sei até que ponto é correto abrir mão da experiência que obtive com programação server side.

[icaromh]

@felipeuntill, quanto a limitações dá uma olhada no projeto rocket.chat. Os caras fizeram com meteor e tu pode tirar várias dúvidas sobre isso com eles.

E qual versão tu esta(va) usando? A última versão melhorou pra caralho a integração com o npm e uma base legal pra pegar essas novas alterações é o https://themeteorchef.com, eles até tem um boilerplate chamado Base

Eu tive uns problemas com meteor também, mas foi mais por não entender alguns conceitos do que com o próprio meteor. 💃

[felipeuntill]

@icaromh Estou utilizando a versão 1.3 desde quando lançou uns 3 meses atrás mas confesso que não tinha visto que o suporte ao npm estava está nativo e ainda estou utilizando o meteorhacks:npm, quanto ao https://themeteorchef.com ele tem sido minha fonte de estudo mas como tive de utilizar o mysql como sgbd muito dos patterns aprendidos com eles tiveram de ser adaptados