A diretiva NgPlural nos permite tratar a pluraridade dos textos em nossa aplicação com muita facilidade.
Ao modificar os assets de uma aplicação Angular, versões antigas podem ficar no cache do browser.
Contornamos isso adicionando um hash no nome dos assets. Assim o browser vai entender que é um novo arquivo.
É só fazer o build da aplicação dessa forma:
$ ng build --prod --output-hashing=all
Contornamos isso adicionando um hash no nome dos assets. Assim o browser vai entender que é um novo arquivo.
É só fazer o build da aplicação dessa forma:
$ ng build --prod --output-hashing=all
Poderíamos usar Angular Material, PrimeNG ou qualquer outra biblioteca de componentes.
Eu defendo que a escolha deva ser feita para cada projeto, pensando em como a biblioteca pode ajudar a desenvolver o que você precisa.
Apesar da AlgaWorks ser parceira oficial da PrimeTek (empresa que desenvolve o PrimeNG) e eu conhecer e admirar muito o trabalho Cagatay Civici (desenvolvedor líder do PrimeNG), eu sempre gosto de fazer uma escolha mais racional, e não emocional.
Dito isso, eu gosto de PrimeNG (o que não quer dizer que eu não goste das outras bibliotecas) porque é muito completa e tem mais de 80 componentes de muita qualidade.
Para projetos grandes, especialmente projetos corporativos (ERPs, telas de cadastros, etc), ter muitos componentes à mão ajuda muito na produtividade.
A PrimeTek tem bastante experiência em desenvolvimento de componentes para JSF, Angular, React, etc.
Eu defendo que a escolha deva ser feita para cada projeto, pensando em como a biblioteca pode ajudar a desenvolver o que você precisa.
Apesar da AlgaWorks ser parceira oficial da PrimeTek (empresa que desenvolve o PrimeNG) e eu conhecer e admirar muito o trabalho Cagatay Civici (desenvolvedor líder do PrimeNG), eu sempre gosto de fazer uma escolha mais racional, e não emocional.
Dito isso, eu gosto de PrimeNG (o que não quer dizer que eu não goste das outras bibliotecas) porque é muito completa e tem mais de 80 componentes de muita qualidade.
Para projetos grandes, especialmente projetos corporativos (ERPs, telas de cadastros, etc), ter muitos componentes à mão ajuda muito na produtividade.
A PrimeTek tem bastante experiência em desenvolvimento de componentes para JSF, Angular, React, etc.
Versionar uma REST API é um mal necessário.
Devemos evitar ao máximo, mas quando a hora chegar, você vai precisar implementar isso de alguma maneira.
As duas principais formas de permitir que os clientes escolham a versão que quer consumir é por URI e Media Type.
Qual forma você prefere? É bom já planejar isso desde o início.
Devemos evitar ao máximo, mas quando a hora chegar, você vai precisar implementar isso de alguma maneira.
As duas principais formas de permitir que os clientes escolham a versão que quer consumir é por URI e Media Type.
Qual forma você prefere? É bom já planejar isso desde o início.
Quando você precisar versionar uma REST API, terá que escolher uma forma para trabalhar com o código-fonte de cada versão.
Eu vejo 3 principais formas de fazer isso:
1) Duplicar completamente o projeto ou criar um projeto do zero
Geralmente, você vai fazer dessa forma quando a mudança no projeto é muito grande, de forma que manter duas versões dentro do mesmo projeto mais atrapalharia do que ajudaria.
Você precisará manter rodando dois ou mais projetos em produção em paralelo.
A vantagem é que as implementações para cada versão ficam totalmente isoladas e não existe nenhum risco de alterar uma versão e afetar outra.
A desvantagem é que você pode acabar com muito código duplicado e ter um custo maior de manutenção.
2) Duplicar apenas a camada de controladores
Você duplica todas as classes de controladores e DTOs para cada nova versão (independente se houve ou não mudanças), mas reaproveita as classes de serviços, repositórios, etc.
A vantagem é que as implementações dos controllers de cada versão ficam isoladas dentro do mesmo projeto e o risco de alterar uma versão e afetar outra é bem pequeno, a não ser alterações feitas em classes comuns, como os serviços e repositórios, por exemplo.
A desvantagem é que você pode acabar com muito código da camada de controladores duplicado.
3) Extrair apenas o código específico que mudou em uma nova versão
Neste caso, você mantém um código base dos controladores que atendem todas as versões (v1, v2, etc) e extrai apenas classes alteradas para uma nova classe (exemplo: ClientesV2Controller), que implementa a nova versão.
A vantagem é que você não duplica código (e isso tende a facilitar a manutenção).
A desvantagem é que exigirá um cuidado especial, porque alterações no código base afetam todas as versões.
Eu vejo 3 principais formas de fazer isso:
1) Duplicar completamente o projeto ou criar um projeto do zero
Geralmente, você vai fazer dessa forma quando a mudança no projeto é muito grande, de forma que manter duas versões dentro do mesmo projeto mais atrapalharia do que ajudaria.
Você precisará manter rodando dois ou mais projetos em produção em paralelo.
A vantagem é que as implementações para cada versão ficam totalmente isoladas e não existe nenhum risco de alterar uma versão e afetar outra.
A desvantagem é que você pode acabar com muito código duplicado e ter um custo maior de manutenção.
2) Duplicar apenas a camada de controladores
Você duplica todas as classes de controladores e DTOs para cada nova versão (independente se houve ou não mudanças), mas reaproveita as classes de serviços, repositórios, etc.
A vantagem é que as implementações dos controllers de cada versão ficam isoladas dentro do mesmo projeto e o risco de alterar uma versão e afetar outra é bem pequeno, a não ser alterações feitas em classes comuns, como os serviços e repositórios, por exemplo.
A desvantagem é que você pode acabar com muito código da camada de controladores duplicado.
3) Extrair apenas o código específico que mudou em uma nova versão
Neste caso, você mantém um código base dos controladores que atendem todas as versões (v1, v2, etc) e extrai apenas classes alteradas para uma nova classe (exemplo: ClientesV2Controller), que implementa a nova versão.
A vantagem é que você não duplica código (e isso tende a facilitar a manutenção).
A desvantagem é que exigirá um cuidado especial, porque alterações no código base afetam todas as versões.