Uma discussão de tópicos sobre o
Meteor raramente
é vista entre falantes de russo (a julgar pelo canal no carrinho e pelo público VK, Habr). É possível uma troca de experiências, mas na maior parte no fórum oficial de meteoros.
Durante muito tempo não houve artigos sobre Habré no Meteor, portanto, eu gostaria de compartilhar nossa história.
Vou falar sobre o nosso projeto, como chegamos ao Meteor e como voamos nele. Vou tentar não entrar em detalhes ou coisas muito específicas - vou deixá-los para discussão ou um artigo separado.
Sobre o projeto
Temos uma escola de programação on-line para crianças.
A PolinaV escreveu
um artigo sobre como fazemos isso online. No início de 2018, começamos a desenvolver ativamente nosso sistema - Gena.
Precisávamos do gene por vários motivos:
- um grande número de ferramentas diferentes - excel, um serviço para manutenção de horários, formulários, etc;
- trabalhar com ferramentas separadamente não era conveniente.
Para a primeira versão, destacamos a funcionalidade principal:
- gerenciamento de cronograma;
- gestão de estudantes / formadores;
- gerenciamento de tarefas internas.
Calculamos o número de usuários e a quantidade de dados que serão gerados. Essas informações e um plano aproximado de desenvolvimento nos ajudaram a estabelecer a arquitetura futura do Genes.
Gene e Meteoro
Eu experimentei o Meteor em 2016, quando precisei fazer alguns protótipos simples. Naquela época, eu tinha as habilidades de C # (mas não ASP), PHP e um pouco de JS.
Eu queria ter um idioma para a frente e para trás, para não complicar o projeto e não duplicar a lógica (talvez eu tenha mentido um pouco sobre protótipos simples :)). Portanto, decidi escolher apenas JS e NodeJS e MongoDB para ele.
Para mim, assim como para o herói
deste artigo, o desenvolvimento da web era um monte de nomes obscuros. E como já havia uma experiência de desenvolvimento, entendi que existem soluções prontas que permitem que você "faça o trabalho" sem se preocupar com o resto.
Não me lembro de como o Meteor foi encontrado, mas ele me subornou com várias coisas:
- Fácil de instalar / configurar. Um comando no console - e é seu;
- canal de transferência de dados pronto (WebSocket + DDP );
- banco de dados embutido - MongoDB (+ minimongo );
- uma ferramenta simples para escrever UI - Blaze ;
- boa documentação e artigos / vídeos relacionados.
Depois de implementar vários protótipos, comecei a acompanhar o desenvolvimento do Meteoro, estudar o interior e ver pequenos projetos para mim.
E agora chegou a hora de escolher uma ferramenta para a implementação dos Genes. Omitirei os detalhes da busca por outros instrumentos, deixarei argumentos a favor do meteoro:
- como escrevi acima - tudo em uma caixa;
- Podemos sacrificar o desempenho e o consumo de recursos em troca da facilidade de desenvolvimento;
- queremos obter rapidamente novos recursos, para que mais tarde possam ser aprimorados ou descartados;
- é possível por um curto período de tempo (2-3 dias) conectar o JS do desenvolvedor ao projeto;
- Existe um banco de dados de pacotes prontos.
Digo separadamente sobre o
Blaze - tomei deliberadamente uma solução mais simples para não perder tempo estudando o React / Vue mais complexo (sim, eles não entraram no hype).
Para manter tarefas e documentação, usamos o Jira + Confluence. O código foi estabelecido em Bitbucket.
Como resultado, houve uma opinião:
- se você tem algo muito simples, use JS / CSS / HTML bruto e faça-o (aterrissagem, por exemplo);
- se houver requisitos específicos para desempenho, recursos, funções - procure-o;
- em outros casos - adote uma estrutura pronta, por exemplo, Meteor. Se você cozinhar corretamente, não deverá haver problemas.
Processo de desenvolvimento
Após a seleção da ferramenta, a fase de implementação do plano começou. Nem sempre pensamos nos requisitos até o fim; portanto, às vezes precisamos refazer o recurso várias vezes. Também temos muitas idéias e tentamos implementá-las e testá-las em usuários reais o mais rápido possível.
A estrutura do projeto (a estrutura de pastas e arquivos) ajuda a evitar perguntas sobre o que e onde deveria estar. Isso está escrito na
documentação . Escrever código facilmente suportável e extensível é mais fácil quando há uma separação clara. A funcionalidade da interface do usuário é dividida em componentes, o que permite isolar os blocos de funções e reutilizá-los. Ao refatorar, você não quebra o piso do projeto :).
Existem muitos
pacotes prontos que resolvem certos problemas. Por exemplo, pronto para uso, o Meteor fornece um gerenciamento de contas (registro, autorização etc.), enviando e-mail. Terceiros resolvem outros problemas. Alguns deles são uma camada para pacotes
npm , portanto, o banco de dados de soluções prontas é muito grande.
Meu erro foi recusar os testes. Essa decisão foi para economizar tempo, porque "os clientes não veem os testes". No entanto, observando a situação com erros emergentes em Jire, percebi que era hora de mudar a abordagem. Eles retornaram os testes e começaram a escrever no TDD. Além disso, depois que o código entrou no ramo de desenvolvimento, eles começaram a executar testes no
CircleCI para garantir que ninguém quebrasse nada.
Para manter o estilo de código, o ESLint +
mais bonito foi configurado . Isso evita correções de estilo e erros ridículos no estágio de consideração do PR (solicitação de recebimento). E para que o código "ruim" não chegasse ao git, o
Husky foi configurado - uma ferramenta que pode executar as tarefas necessárias no estágio de confirmação (e não apenas). Portanto, antes que o código entre no commit, ele passa a verificação através de eslint e mais bonita.
Vale mencionar separadamente um importante ponto negativo - a velocidade de construção do projeto. A primeira vez que a montagem leva cerca de 30 segundos, dependendo do ferro. Além disso, ao alterar o código, o processo leva cerca de 5 a 10 segundos. Em um ferro fraco, os números podem ser maiores. Eu uso um MacBook pro de 15, i7, 16gb, estou bem.
Eles decidiram lançar o gene no Digital Ocean. Há uma razão - o preço.
Hospedagem oficial para meteoros queridos. A AWS é mais barata, mas mais complicada que o DO. Existem outras alternativas, mas resolvidas no DO.
Vôo
No momento, podemos ter simultaneamente até 100 usuários conectados ao Gene. Isso não é muito, mas também temos uma grande margem de segurança. Esperamos suportar 1000CCU na configuração atual.
Até o momento, dois servidores de 10 $ + 5 $ proxies são suficientes para nós (para balanceamento). Cada servidor é nodejs app + MongoDB. O servidor para monitoramento é iniciado separadamente. Previmos o crescimento do tráfego, portanto, teremos tempo para implantar novos servidores (aumentar a gota e adicionar uma linha à montante).
Derramar uma nova versão do Genes é um prazer. Para fazer isso, um pequeno script foi escrito que coleta o projeto no tar (com o
comando meteor build ), faz o upload para o servidor, descompacta, executa o
npm i e inicia o daemon. Geralmente leva 1 minuto.
Se você omitir os detalhes, algo assim (se for interessante, prepararei a essência):
Observamos Gena através de
Kadira (foto no início do post). Eu tive que dançar um pouco com um pandeiro para correr nas minhas instalações, mas valeu a pena. Tudo é claro e compreensível.
Ainda não havia problemas com a estabilidade. Falhas acidentais ou vazamentos de memória não são observados.
Conclusão
Lançamos o gene meio ano após o início. A equipe cresceu, assim como Gene. Provavelmente, superaremos o monólito e haverá microsserviços, filas, pacotes individuais etc. Mas esta é uma história completamente diferente ...
O meteoro está mudando. Para aqueles que tentaram na versão 1.4 e abaixo, recomendo consultar a
lista de alterações . Espero que você seja agradavelmente surpreendido.
Lista de materiais úteis sobre o meteoro:
Quem trabalha com um meteoro ou está interessado - entre na nossa sala de bate-papo em um telegrama.
Peço desculpas se não divulgou nenhum tópico importante, tentarei responder nos comentários.