Ao longo dos últimos meses os requisitos do projeto cresceram e os seus gestores se depararam com alguns dilemas, e com um grande número de decisões de projeto, que ficaram sem decisão... Podemos reduzir drasticamente esse número, adotando convenções consensuais. Essas convenções foram discutidas na última semana, a seguir um resumo:
Cada microservice descrito (e satisfazendo na sua implementação) com OpenAPI.
Todos os microservices do backend sob um só domínio, orquestrados por um API-Gateway,
Todos os dados mantidos em uma só base de dados PostgreSQL v9.6+, transparente, com tabelas principais abertas à consulta pública através de PostgREST.
Todos os "dados de longo-prazo" armazenados em "backup" git, através de tabelas CSV e arquivos XML (HTML5 poliglota).
Decisões de linguagem de programação
Preferência por NodeJS (Javascript). PS: justifica-se em parte por ser a mais popular atualmente na OKBR e a que mais cresce no mundo, em parte por seu potencial estratégico de unificar backend e frontend. Stored procedures do PostgreSQL: as mais simples em SQL, complexas em PLpg/SQL ou, quando for possível reuso do código NodeJS, em PL/V8.
Quando o reuso de uma biblioteca complexa for superior a 80%, manter a biblioteca na sua linguagem nativa e buscar reuso por binding (ex. chamada direta de classes e métodos C++ via driver pelo NodeJS); plugando o serviço no API-Gateway; ou, quando for apenas uso para importação de dados, via comando de terminal. Nesse caso cabe manter um fork do projeto se houverem adaptações.
Sempre que houver possibilidade de reuso de pelo menos 20% do código, e a linguagem for compatível com o conjunto adotado pela OKBR, reusar. Exemplo: uso de legados Python do Diário Livre (TrazDia).
Decisões por framework e organização do código NodeJS
Webservices complexos e com comunidades e usos mais amplos, como o TrazDia e o conversor de PDF, se tornariam projetos independentes, ou seja, mantidos por um outro git. Idem fork, a exemplo do que fizemos com o projeto Poppler, a biblioteca de conversão de PDFs especializada nos diários oficiais.
Ao longo dos últimos meses os requisitos do projeto cresceram e os seus gestores se depararam com alguns dilemas, e com um grande número de decisões de projeto, que ficaram sem decisão... Podemos reduzir drasticamente esse número, adotando convenções consensuais. Essas convenções foram discutidas na última semana, a seguir um resumo:
Diretivas gerais
Backend baseado em arquitetura SOA, estruturada em REST microservices.
Cada microservice descrito (e satisfazendo na sua implementação) com OpenAPI.
Todos os microservices do backend sob um só domínio, orquestrados por um API-Gateway,
Todos os dados mantidos em uma só base de dados PostgreSQL v9.6+, transparente, com tabelas principais abertas à consulta pública através de PostgREST.
Todos os "dados de longo-prazo" armazenados em "backup" git, através de tabelas CSV e arquivos XML (HTML5 poliglota).
Decisões de linguagem de programação
Preferência por NodeJS (Javascript).
PS: justifica-se em parte por ser a mais popular atualmente na OKBR e a que mais cresce no mundo, em parte por seu potencial estratégico de unificar backend e frontend.
Stored procedures do PostgreSQL: as mais simples em SQL, complexas em PLpg/SQL ou, quando for possível reuso do código NodeJS, em PL/V8.
Quando o reuso de uma biblioteca complexa for superior a 80%, manter a biblioteca na sua linguagem nativa e buscar reuso por binding (ex. chamada direta de classes e métodos C++ via driver pelo NodeJS); plugando o serviço no API-Gateway; ou, quando for apenas uso para importação de dados, via comando de terminal.
Nesse caso cabe manter um fork do projeto se houverem adaptações.
Sempre que houver possibilidade de reuso de pelo menos 20% do código, e a linguagem for compatível com o conjunto adotado pela OKBR, reusar. Exemplo: uso de legados Python do Diário Livre (TrazDia).
Decisões por framework e organização do código NodeJS
Seguir exemplos de mherman.org/2016/restful-api-with-node-and-postgres para o caso de código mais enxuto, senão seguir defaults Express e melhores práticas da comunidade.
Decisões de modularização
Webservices complexos e com comunidades e usos mais amplos, como o TrazDia e o conversor de PDF, se tornariam projetos independentes, ou seja, mantidos por um outro git. Idem fork, a exemplo do que fizemos com o projeto Poppler, a biblioteca de conversão de PDFs especializada nos diários oficiais.