API Architecture for Complex Applications

Tudo que você precisa saber para criar aplicações escaláveis e manuteníveis.

Transcript

1. for Complex Applications Tudo que você precisa saber para criar aplicações escaláveis e manuteníveis. API Architecture
2. Christopher Enytc Developer Evangelist at Pagar.me  chrisenytc  chrisenytc
3. Jornada A uma nova realidade 3 2015 2016 2013 PResente Após poucos anos, estou palestrando na primeira conferência de Node.js do Brasil e com mais de 90 repositórios no GitHub, sendo a maioria para usar com Node.js. Mudança Da noite pro dia fui chamado para vir para São Paulo trabalhar pela primeira vez em uma empresa. Começo Sem saber o que me esperava no futuro, comecei a estudar Node.js.
4. Mas quando e porque criar uma arquitetura própria para sua aplicação? 4
5. quando 5 Seu produto precisa de uma aplicação complexa e que dure por vários anos. Você precisa ter controle total de toda a estrutura de arquivos da sua aplicação. As soluções atuais limitam o crescimento e manutenção da sua aplicação.   
6.  porque 6 A estrutura inicial da sua API vai definir o futuro do seu produto. Você pode definir tudo voltado para as necessidades da sua aplicação. Está menos exposto a mudanças de arquitetura e compatibilidade de versões.  
7. cuidado com más decisões 7 tempo Decisões erradas também podem fazer você e sua equipe perder muito tempo e dinheiro no futuro. Quase nunca reescrever uma aplicação em produção é viável para a maioria das empresas, e mesmo se for, você vai precisar parar boa parte ou toda a sua equipe e contratar mais pessoas para cuidar das demandas recorrentes. Estrutura É preciso tomar muito cuidado ao iniciar uma arquitetura própria. Escolhas erradas podem prejudicar muito a sua aplicação conforme ela for crescendo. equipe Decisões erradas podem influenciar muito na sua equipe, principalmente decisões estruturais. É preciso tomar muito cuidado pois essas decisões podem fazer desenvolvedores ficarem desapontados com a aplicação e sem confiança de trabalhar com ela, fazendo você perder a oportunidade de trabalhar com grandes desenvolvedores.
8. 8 partindo para a ação Depois de tudo isso, vemos que é uma responsabilidade muito grande criar uma API realmente escalável e manutenível, que possa operar em produção por vários anos, sem limitar o crescimento do produto ou diminuir a produtividade da equipe. Para isso, vamos definir um percurso da nossa trajetória criando essa nova arquitetura. ambiente estrutura arquitetura
9. estrutura de arquivos 9
10. 10  Estrutura principal Define um conjunto de módulos principais: bin, config, lib.  Lib Define os conceitos da arquitetura.  API Define um conjunto de módulos que gerenciam a API em si.
13. arquitetura 13
14. models schemas helpers endpoints services adapters conceitos
15. promises coercion typed errors updaters policies responders conceitos
16. adapters Responsáveis por abstrair serviços ou bibliotecas de terceiros. 16
18. endpoints Responsáveis por servir requisições HTTP ou outros protocolos desejados. 18
20. Services Responsáveis por implementar a lógica de negócio da aplicação de forma idempotente. Podendo ser usado por várias formas de transmissão sem alterar a assinatura dos métodos e podendo ser usado em mais de um Endpoint. 20
22. models Responsáveis por definir schemas e regras relacionados ao banco de dados. 22
23. helpers Responsáveis por separar métodos úteis que não fazem parte de um Service ou que é usado em mais de um Service. 23
25. responders Responsáveis por definir o resultado da resposta da requisição, levando em conta o contexto atual do usuário em caso de vários níveis de acesso e propriedades privadas que apenas certos usuários podem acessar. 25
27. updaters Similar aos Responders. Sua função é atualizar determinadas propriedades de um recurso dependendo do contexto atual do usuário e dos níveis de acesso daquele recurso. Permitindo atualizar certas propriedades privadas com segurança. 27
28. schemas Responsáveis por definir um conjunto de regras para validação de parâmetros pelo cliente que fez a requisição. http://json-schema.org 28
29. policies Responsáveis por definir um conjunto de regras de permissão para um recurso ou um conjunto de recursos. Pode atuar em vários tipos de protocolos. 29
30. typed errors Responsáveis por definir um conjunto de tipos para todos os erros gerados pela aplicação, permitindo o tratamento de erros de uma forma segura e concisa. Uma das vantagens é que a aplicação só vai exibir para o usuário erros específicos e definidos pela aplicação, em vez de erros genéricos gerados internamente. 30
33. promises Responsáveis por gerir todas as ações executadas na API. Tudo retorna uma Promise e todos os erros que acontecerem em todos os fluxos da aplicação, desde o bootstrap até a resposta da requisição, são tratadas em apenas um lugar, tornando o código mais limpo, confiável, legível e auto-explicativo. 33
35. type coercion Coerção de tipo é a conversão de um tipo de objeto para um novo objeto de um tipo diferente de conteúdo similar. 35 importância Assim como em aplicações full-stack, quando você está criando uma API, você nunca deve confiar no input do usuário, mas muitas vezes é possível contornar certos casos. Por exemplo: seu Schema aceita apenas o tipo boolean, mas o seu usuário enviou um inteiro 1. Você pode fazer uma coerção do tipo, dado que 1 também é considerado como valor booleano em algumas linguagens.
36. versionamento Praticamente uma obrigação para toda API. 36 v3 v1 v2
37. 37  Há quem vive sem Criar APIs sem versionamento seria o mesmo que criar uma religião, sempre vai ter as mesmas regras, nada nunca pode mudar e tudo é verdade. Essa é a pior coisa que pode acontecer com uma API. A partir do momento que você tem seu primeiro cliente, você tem um compromisso de manter a compatibilidade da integração, mas muitas vezes, como a ciência, você descobre que você estava errado e que há um jeito melhor de fazer algo, você aprende com seus erros, e vai melhorar muito para os seus novos clientes. Mas você não tem versionamento, e não pode fazer nenhuma alteração para não afetar seus clientes antigos. Resultando em uma aplicação legada e de difícil manutenção.
38. boas práticas 38 data Usar uma data para definir as versões da API é uma das melhores formas. Usado também pelo Stripe e Twilio. header O método mais recomendado para fazer versionamento é por HTTP HEADER. Várias empresas como Stripe usam essa forma. changelog Mantenha um histórico das mudanças que ocorreram nas versões, e também permita que usuários possam mudar de versão em suas configurações
39. autenticação Os melhores métodos para se usar 39  
40. header Quando se trata de Autenticação de APIs, a autenticação por Header sai ganhando. É um dos melhores e mais usados métodos de autenticação nas APIs de diversos serviços famosos. 40 Bearer Auth Basic Auth Authorization: Basic username:password Authorization: Bearer token1234
41. rate limiting É usado para limitar o número de requisições abertas sendo feitas simultaneamente a sua API, evitando abusos e economizando a utilização de recursos como conexão de socket e memória. 41 Importância É de extrema importância que aplicações que recebem milhares de requisições, implemente rate limiting para evitar abusos e sobrecargas com requisições iguais sendo feitas simultaneamente. Se você não conhecia Rate Limiting, aqui está uma das melhores libs para usar com Express. npmjs.com/express- rate-limit
42. request id É usado para identificar usuários de forma única, uma das coisas quase obrigatórias ao se criar uma API. 42 Importância O request id é uma daquelas coisas simples, mas que causa um impacto absurdo. Principalmente aplicações que recebem milhares de requisições por dia. Como cada requisição tem um X- Request-ID associado a ela, é possível pesquisar em logs para encontrar possíveis problemas relatados por usuários de forma fácil. Se você não conhecia Request ID, aqui está uma das melhores libs para usar com Express. npmjs.com/request- id
43. ambiente 43
44. itens importantes Porque que um ambiente seguro e confiável também faz parte da arquitetura de uma API. Safe Ter um ambiente estável, seguro e confiável, com facilidade de monitoramento é tudo.  Logging Saber o que acontece na sua aplicação, é uma das coisas mais importantes.  style guide Manter uma aplicação inteira seguindo os mesmo padrões, é o segredo para manutenção rápida e ágil.  security Focar em ficar protegido, e sempre monitorando vulnerabilidades em dependências.  44
45. Logging Bunyan é uma das melhores ferramentas para capturar logs em APIs. 45
46. Logging Logentries é uma das melhores ferramentas para gerenciar logs de diversas fontes. 46
47. style guide Hound CI é um dos melhores CIs para testes de style guides. 47
48. security Snyk é uma ferramenta essencial para aplicações complexas e ambientes críticos, com ele é possível ver os riscos aos quais você está exposto. 48
49. security Inside Security, é uma das mais completas newsletters sobre segurança e vulnerabilidades. 49
50. safe N|Solid é um dos ambientes para Node.js, com features incríveis, do monitoramente a analise de vulnerabilidades. 50
51. safe 51
52. safe 52
53. safe 53
55. A arquitetura demonstrada está disponível no repositório abaixo. É uma Proof of Concept e ainda há muito trabalho a ser feito, mas espero que ela possa inspirar vocês caso precisem. 55 http://github.com/chrisenytc/castiel
56. 56 obrigado         