Zombando de um monorepo

(22 de novembro de 2020)

Esta é uma imagem real de nosso ambiente de desenvolvimento depois de criarmos um servidor de simulação para nosso repo

Com uma quantidade crescente de serviços sendo criada em nosso back-end, nosso desenvolvimento de front-end começou a ser impactado por quantos repos e servidores você precisava para instalar localmente para iniciar o front-end. E se também levarmos em consideração nosso ( retrabalho da arquitetura de frontend ), sabíamos que tínhamos que tomar medidas para ter um experiência de desenvolvimento rápido e suave. É aí que entra o nosso servidor de simulação monorepo.

Um pouco sobre LumApps

Se você não sabe sobre LumApps , somos um empresa de tecnologia global com equipes R & D na França que fornece aos nossos clientes um SaaS Digital Workplace solução, que cria um espaço de trabalho holístico, integrado com várias suítes e ferramentas de colaboração. Quer saber um pouco mais sobre nós? Acesse LumApps.com e dê uma olhada!

O que precisávamos

Até alguns anos atrás, nosso aplicativo front-end era bastante simples de lançar em seu próprio ambiente de desenvolvimento para começar a codificar. Você executou o front-end e o back-end e pronto! Mas desde que a empresa e o aplicativo cresceram exponencialmente nos últimos dois anos, com novos serviços criados e novos desenvolvedores chegando para desenvolver o produto, inicializar o aplicativo localmente não era tão fácil como costumava ser.

Esses novos serviços significavam que você precisaria configurá-los em sua máquina, o que não só demorava para configurar, mas também muita CPU, criando uma combinação realmente difícil para nossos ambientes de desenvolvimento. Precisávamos de um sistema que nos permitisse:

  • Remover essas dependências de serviços para desenvolvimento local e ter um servidor único que servia os dados que o frontend precisava para o desenvolvimento local e, portanto, aumentando o tempo de desenvolvimento local 🚀
  • Crie um conjunto de dados que todas as equipes possam reutilizar para desenvolver suas funcionalidades. Isso significa compartilhar os dados entre as equipes e permitir que essas equipes criem seus próprios conjuntos de dados para remover / adicionar configuração para cada configuração de equipe específica 🛠
  • Tenha um conjunto consistente de dados que pode ser reutilizado para testes de unidade e integração ✅

Como fizemos

Depois de alguma pesquisa , encontramos um módulo npm bacana chamado json-server que nos permitiu criar uma API REST completa falsa com realmente nenhuma configuração. É realmente uma ferramenta incrível , uma vez que não apenas permite simular dados e criar um servidor, mas fornece muitos funcionalidades básicas da API prontas para usar, o que torna essa ferramenta realmente o próximo nível quando se trata de simulação. Com ele, poderíamos, por exemplo, executar um POST para criar um recurso e da próxima vez que fizermos um GET para recuperar a lista de recursos, o recurso criado recentemente estaria lá! Também nos permite criar express js middlewares que podem ser usados ​​para ajustar solicitações e respostas, dando-nos acesso total para mudar o que quisermos!

json-server

Obtenha uma API REST completa falsa com codificação zero em menos de 30 segundos

www.npmjs.com

Além disso, criamos um pequeno arquivo node js que nos permitiu gerenciar facilmente esses mock arquivos em um monorepo.Basicamente, json-server precisa de um ponto de entrada json onde residem os dados simulados, mas como estamos usando uma arquitetura monorepo, queremos cada pacote deve ter seus próprios dados fictícios então eles são os proprietários desses dados e, além disso, nos permite ver claramente o endpoints que um pacote consome. Este arquivo node js é um script executado antes de json-server e:

  • Percorre cada um dos pacotes em nosso espaço de trabalho e procura por arquivos denominados api.json no _mocks pasta e combina todos eles em um único arquivo com todos os dados de cada pacote. Ele também leva em consideração as outras json-server configurações, como rotas ou middlewares e os coloca todos juntos em um único local
Uma pasta de usuário com uma subpasta chamada _mocks e 3 arquivos: api.json, routes.json and user.middleware.js
Esta é a aparência de nosso pacote de usuário com seus próprios mocks definidos
  • Grava em uma pasta predefinida esses arquivos combinados e executa json-server com esses arquivos como entrada .
  • Tudo isso é executado em um único comando yarn mocks que cria os arquivos e inicia json-server .
  • Também permitimos que cada módulo criasse diferentes cenários para suas respostas de API, que chamamos de substituições . Cada pacote pode criar quantas substituições quiser, que são um subconjunto dos dados que a API retorna, com diferentes valores substituídos e alterados para que a API retorne um cenário diferente. Portanto, por exemplo, nossa resposta da API para nosso serviço de notificações é assim:
Uma resposta da API para nosso serviço de notificações com os itens de chaves, notificações não lidas com um valor de 5 e mais em verdadeiro
Nosso serviço de notificações retorna uma lista de notificações para exibir, quantas delas não foram lidas pelo usuário e se há mais notificações para buscar

Mas e se quiséssemos iniciar facilmente um front-end onde o usuário não tem nenhuma notificação? Nesse caso, criamos a substituição no-Notifications.api.json que substitui este arquivo:

Uma resposta da API para nosso serviço de notificações com as notificações não lidas com um valor de 0 e mais em falso
Substituir para um cenário onde não há notificações para o usuário atual

No nível da pasta, nosso pacote de notificações se parece com isto:

Temos muitos cenários diferentes para o nosso centro de notificações 😅

E para aplicar essas substituições, basta iniciar yarn mocks -override sem notificações e nosso arquivo node js procurará as diferentes substituições criadas em cada pacote com o nome sem notificações

e mesclam profundamente seus valores com os valores originais de cada resposta da API. Isso também significa que se houver outros pacotes que desejam criar uma substituição para o cenário sem notificações , eles também podem fazer isso ! Eles só precisam criar um arquivo chamado no-notifications.api.json em seu _mocks pasta.

Finalmente, você também pode aplicar várias substituições de uma vez fazendo yarn mocks -override sem notificações, admin, sem postagens. Isso aplicará essas substituições uma após a outra, substituindo cada chave nas respostas da API na ordem fornecida.

O que vem a seguir

Ainda precisamos passar por mais alguns cenários que queremos abordar para permitir que nossos desenvolvedores tenham uma experiência de desenvolvimento mais fluida:

  • Crie simulações automaticamente a partir de um serviço de back-end remoto.
  • Valide periodicamente essas simulações contra um serviço de back-end remoto para verificar se a resposta da API não mudança.
  • Abra o código deste pequeno nó js script para aqueles que estão usando monorepos e quiser reutilizar esse código pode fazer isso! Fique ligado para futuros desenvolvimentos neste assunto!

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *