6. MICROSERVIÇOS
PRÓS
• Aumento de resiliência
• Escalabilidade independente
• Deploy fácil, independente e frequente
(CI/CD)
• Independência de tecnologias e de fácil
migração
• Fácil debug específico
• Pequenos times especializados
• Testes automatizados
• Fácil para dev novo no time
• Reusabilidade e Composição
• Desacoplamento e alta coesão
CONTRAS
• Manutenção (DevOps)
• Versionamento (cuidado)
• Latência
• Transação entre serviços
• Testes de integração e monitoramento
• Integração entre times
• Documentação (api)
• Tratar falhas
• Cuidado com granuralidade (quantidade
serviços)
11. PROBLEMAS DO ID AUTOINCREMENT
• Fácil extrair certas informações (cria um usuário novo e pelo id
você sabe quantos usuários tem na base)
• Enumerar entidades (se não tiver tratamento, basta trocar o id
na url para outro número)
• Não é único entre as tabelas (existe uma entidade 1 em todas
as tabelas)
• Não é possível usar em sistemas distribuídos
• Muito difícil migrar dados para outro banco ou usar como
replicação (MySQL para Elasticsearch por exemplo)
13. UUID
• V4: 362e80f5-af9a-4d68-86da-5bf014dcafc1
• V4 COMB
• 8e208169-a0d1-419d-b17f-913b9985b8ac
• 8e21f643-a18e-4800-9c8d-4a71916a886b
• Geração pode ser descentralizada.
• Você não consegue enumerar as entidades
• Você não sabe quantos registros tem na tabela
• Você não precisa falar com a database para gerar um valor
“The number of random version-4 UUIDs which need to be generated in order to
have a 50% probability of at least one collision is 2.71 quintillion.
This number is equivalent to generating 1 billion UUIDs per second for about
85 years.” - Wikipedia
18. SÍNCRONO
PRÓS
• Baixa complexidade
• Fácil tratamento de erro
• Resposta em “real-time”
CONTRAS
• Cada serviço tem que estar
disponível
• Resposta lenta
19. ASSÍNCRONO
PRÓS
• Resposta imediada, não
precisa esperar todos os
serviços responderem
• Desacoplamento entre os
serviços
• Serviço pode não estar
disponível na hora
• Isolamento de falha
CONTRAS
• Arquitetura complicada
• Tratamento de erro
• Acoplamento ao “message
broker”
• Alta latência se fila cheia
• Custo de monitoramento
• Nem sempre possível (listar
itens na tela)
24. API - STATUS HTTP
2XX
• 200 – OK
• 201 – CREATED
• 202 – ACCEPTED
• 204 – NO CONTENT
4XX
• 400 – BAD REQUEST
• 401 – UNAUTHORIZED
• 403 – FORBIDDEN
• 404 – NOT FOUND
• 405 – METHOD NOT ALLOWED
• 409 – CONFLICT
• 422 – UNPROCESSABLE ENTITY
• 429 – TOO MANY REQUESTS
5XX
• 500 – INTERNAL SERVER ERROR
• 502 – BAD GATEWAY
• 503 – SERVICE UNAVAILABLE
• 504 – GATEWAY TIMEOUT
25. SEGURANÇA
• Não confie em ninguém (filtrar/validar toda entrada, escapar
toda saída)
• Se prepare para o pior cenário
• Princípio do menor privilégio
• Se não testou, não assuma que funciona
• SQL Injection
• Cross-Site Scripting (XSS)
• https://www.acunetix.com/websitesecurity/php-security-1/
(exemplos)
30. THE SEPARATION OF CONCERNS (SOC)
PRINCIPLE
Os conceitos ou preocupações são os diferentes aspectos da
funcionalidade do software. Por exemplo, a "lógica de negócios"
do software é uma conceitos, e a interface pela qual uma pessoa
usa essa lógica é outra conceitos.
A separação de conceitos é manter o código para cada uma
dessas responsabilidades separadas. Alterar a interface não deve
exigir a alteração do código de lógica de negócios e vice-versa.
31. ARQUITETURA DE 3 CAMADAS
Idéia de usar SoC, é mover
sua regra de negócio para
fora da sua camada de
roteamento (resources)
32. BOAS PRÁTICAS
• Não coloque sua regra de negócios dentro dos controladores!
• Um dia você pode precisar reutilizar em um outro lugar.
• Seu código fica mais “macarrônico”
• Dificulta a construção de teste unitário
• Dificulta a legibilidade do código
• Coloque seus SQL/DataAccess na camada correta
35. USE A CAMADA PUB/SUB
O padrão pub/sub vai além da arquitetura clássica de 3 camadas, mas
é extremamente útil.
Um endpoint simples que cria um usuário agora, pode querer chamar
serviços de terceiros, talvez para um serviço de análise ou talvez iniciar
uma sequência de e-mail.
Mais cedo ou mais tarde, essa simples operação de "criação" estará
fazendo várias coisas e você terá 1000 linhas de código, tudo em uma
única função.
Isso viola o princípio da responsabilidade única.
37. Chamadas imperativas não é a melhor maneira de fazer isso.
Uma abordagem melhor é emitir um evento, ou seja, "um usuário se
inscreveu com este e-mail".
E você está feito, agora é da responsabilidade dos ouvintes fazer o
trabalho deles.
39. • Agora você pode separa seu eventos em vários arquivos, de acordo
com a afinidade de cada um
40. FUJA DO ASYNC/AWAIT HELL!
• Encontre funções que dependam da execução de outras declarações
• Agrupe códigos dependentes em funções assíncronas
• Execute estas funções assíncronas simultaneamente