Arquitetura de Software Modular com NPM

[abalad]

Estou fazendo algumas pesquisas para a construção de uma boa arquitetura para um Software que irei desenvolver, porem me veio a ideia de criar partes deste Software como módulos específicos e utilizar o NPM para gerenciamento destes pacotes, visto que possivelmente irei precisa reutilizar estes pacotes/módulos em outros projetos.

Alguém já teve uma ideia semelhante ou ja precisou fazer um Software com este requisito não funcional como um dos pontos fortes ?

[bernardodiasc]

Veja se algo assim serve para seu propósito https://lernajs.io/ ou se a dúvida é outra. :)

[abalad]

@bernardodiasc Vou dar uma Lida e escrevo o que echei. A principio muito Obrigado ;)

[abalad]

@bernardodiasc A ideia seria esta mesmo, mas minha duvida é se alguém já utilizou este tipo de arquitetura para projetos deste porte, em que a separação de módulos e a reutilização deles é primordial.

Queria mais uma opinião sobre se alguém já implementou isto em algum de seus projetos.

[bernardodiasc]

Sobre quem utiliza o metodo "monorepo":

Projects like Babel, React, Angular, Ember, Meteor, Jest, and many others develop all of their packages within a single repository.

Aqui preparamos todo o setup dos nossos pacotes compartilháveis usando LernaJS, PORÉM, por falta da coordenação/planejamento, a implementação foi encostada e ainda estamos utilizando métodos mais manuais (se é que não ter método pode se chamar de método). A experiência foi um pouco difícil pra fazer o setup, em adaptar o que ja existia para esse modelo, mas isso pelo fato de termos um setup cheio de peculiaridades.

[paulopaquielli]

@abalad A galera aqui do trabalho usa um repo npm privado com vários componentes que nós usamos em vários projetos. A nossa idéia é colocar no repositório apenas libs que são compartilhadas em mais de um projeto, caso contrário não faria muito sentido. As vantagens de manter em um repo desse é a facilidade de utilizar diferentes versões daquela lib (http://semver.org/) :)

[abalad]

A minha ideia seria bem esta mesmo de monorepo como o @bernardodiasc mencionou porem seguindo esta linha de criação dos mudulos como @paulopaquielli passou. Um exemplo que tomei foi o repo do Angular 2 . Eles mantem os modulos core, http, etc.. Todos em um mesmo repositório (monorepo), porem subdividem os módulos mantendo a dependência entre um ou outro modulo.

Encontrei este artigo: https://jaxenter.com/microservices-mono-repo-vs-multiple-repositories-130148.html me esclareceu bem a ideia.

[felipeuntill]

Por experiência própria recomendo que você fuja deste tipo de arquitetura, aproximadamente um ano e meio atrás adotei uma solução similar em um projeto de médio porte usando pacotes privados no npm.
Após implementação, o processo de atualização/correções começou a consumir muito do tempo de desenvolvimento e optamos por unificar os projetos fisicamente pra voltarmos a não depreender tempo publicando e atualizando versões de pacotes.

[abalad]

@felipeuntill Muito Obrigado pela sua resposta. Pensando neste caso que você mencionou realmente se tornara mesmo esta questão. Mas quando vocês voltaram pra a forma anterior, como que vocês controlaram as dependências entre projetos ?? Não digo dependências de classes no mesmo projeto mas sim entre projetos. Foi feita uma separação entre módulos, plugins, pacotes ?

[felipeuntill]

Nossa arquitetura é fortemente embasada em DDD nossa ideia inicial era segregar os domínios em pacotes no NPM, após vermos que este modelo de distribuição não atendia optamos por uma solução pratica e que exigiria pouca intervenção para migrar o código existente.

Nossos domínios são divididos em projetos diferentes no repositório de código(github) e cada um possui 3 branchs (Development => Assurance => Stable), sendo que cada uma destas corresponde exatamente ao nosso processo de desenvolvimento e entrega.

Domínios quais são compostos unicamente de serviços são consumidos em rest, não exigindo qualquer relacionamento programático, quanto aos domínios que compartilham códigos, optamos por disponibilizar os respectivos através de um arquivo index.js que expõe o conteúdo para as demais aplicações via require, então se você está trabalhando em uma aplicação que possui dependência de outro dominio, basta clonar o respectivo(stable) importar o index.js e utilizar seus módulos e classes normalmente.

Para não ficar tão abstrato vou representar abaixo a solução:

Plataforma de Comércio Eletronico(Diretório Raiz)

• Dominio Loja (Stable => Assurance => Release)
  -- Index.js [Retorna os Modulos Marca e Categoria]
  ---- Modulo Marcas
  ---- Modulo Produtos
• Dominio Checkout (Stable => Assurance => Release)
  -- Index.js [Retorna um o Modulo Carrinho]
  ---- Modulo Carrinho [Referência o Modulo Produtos do Dominio Loja Usando algo similar ao Exemplo abaixo]
  import { Produtos } from '../Loja/index';

Acredito que no seu caso uma arquitetura similar segregando conforme suas necessidade atenderia e manteria a agilidade. É valido ressaltar que a cultura do versionamento e fluxo de entrega tem de ser respeitada para garantir qualidade, codar na stable jamais e ignorar os testes de assurance mais ainda.

@abalad Escrevi no iPad e morrendo de sono portanto, ignore a ortografia e erros de gramática...

[bernardodiasc]

Bem maneira essa organização @felipeuntill, aqui temos algo parecido, mas usando Docker e NPM.

O que tem no Docker da pra fazer manualmente, seria algo assim:

setup dependency-package

1. git clone [email protected]... /app/src/dependency-package
2. cd /app/src/dependency-package
3. npm install
4. npm link

setup main-application

1. git clone [email protected]... /app/src/main-application
2. cd /app/src/main-application
3. npm link @privateNPM/dependency-package
4. npm install

No mainApp importamos o depPkg com import depPkg from '@privateNPM/dependency-package'.

[abalad]

@felipeuntill Que Bacana amigo como você lida com esse "problema", pesquisando um pouco cheguei a conclusão que seria bem desta forma mesmo que irei precisar fazer, porem me veio outra coisa em mente, como gerenciar versões destes dominios para não entrar em um inferno de dependências. O intuito de utilizar o NPM era para ele fazer ele controle por mim. Você chega ter esse problema ?

[felipeuntill]

@abalad Você está procurando sarna para se coçar 😂, se gerir uma arquitetura modular já é trabalhoso imagine versionando os domínios? o time sempre terá de intervir nos projetos para atualizar.

Se você realmente precisar versionar os domínios(não consigo imaginar uma situação onde algo continue usando uma referência de dominio velha) você pode segregar com uma pasta para cada versão.

[gloredo]

Se alguém cair de paraquedas aqui como eu, confira o sistema de plugins que o hapi.js dispõe.