Por algumas vezes trabalhando com arquitetura de soluções de Tecnologia da Informação, aprendi que definir o problema com perguntas esclarecedoras, é a chave de tudo:
- Definir os casos de uso,
- Objetivos do sistema,
- O quê é necessário para o sucesso do projeto?
- Quais são as restrições,
- Confiabilidade desejada,
- Redundância,
- Estabilidade,
- Segurança,
- Disponibilidade % up-time,
- Simplicidade vs. Complexidade,
- Manutenção e Consistência.
Lembra do Teorema de Cap? Aplique em seus projetos.
Uma vez que o componentes necessários ao projeto seja definido com base nas respostas das questões anteriores, os próximos passos são as definições de:
- WebServer,
- Load balancer,
Esses elementos são pontos de falha do projeto e devem receber total atenção.
Para design de sistema móvel, é importante ainda pensar em:
- Acesso offline,
- Cache,
- Como ocorre a atualização das páginas, e
- Otimização round trip.
Como escalar servidores da web? >Balanceadores de carga
- É possível usar um ou vários balanceadores de carga em paralelo,
- Também é possível dividir as aplicações pelos recursos, dessa forma, pode-se equilibrar cada recurso em um grupo de servidores.
Como dimensionar o banco de dados? > Cache
Depois de projetar a distribuição de cargas e balancear os servidores web, é preciso pensar no próximo problema: a Base de dados!
Uma boa prática é armazenar em cache os resultados do banco de dados; para isso seria importante adicionar uma camada de cache extra entre os servidores e o banco de dados:
Pode-se usar o cache na memória ou salvar em disco. Por exemplo, o Redis permite salvar conteúdo/ativos do cache da memória no disco (mas lembre-se: o disco é muito mais lento do que a memória). Existem duas abordagens básicas a se seguir: write-back cache ou write-through cache.
Outra forma de dimensionar o banco de dados é vertical e horizontalmente. Para saber mais, veja aqui.
Como preparar nossos ativos para entregar mais rápido em todo o mundo? > CDNs
A CDN (Content Delivery Network ou Rede de Distribuição de Conteúdo) é muito boa para entregar ativos (js, png, mpeg4, etc) de forma muito rápida, porque ela geralmente estará mais próxima do usuário, fazendo com este, tenha uma experiência de usabilidade e navegação no site, e-commerce ou aplicação, mais fluida e dinâmica.
A arquitetura de CDN irá ajudar sua aplicação da seguinte maneira: o usuário acessa a URL da CDN, o servidor CDN verifica se seu servidor, mais próximo ao requisitante, possui os ativos requisitados; se ele tiver, fará a entrega dos ativos; caso contrário, o servidor CDN acessará o servidor que possui o ativo E carregará e salvará o ativo em seu cache. Então, na próxima consulta a este conteúdo/ativo, será usado o ativo armazenado em cache no servidor CDN.
Existem duas estratégias básicas de CDNs: PULL ou PUSH.
Estratégia Pull:
Nessa técnica, o usuário acessa a URL da CDN e o servidor CDN verifica se o servidor mais próximo à requisição, possui o ativo; caso contrário, o servidor acessará o servidor origem, que possui o ativo; a CDN irá carregar o ativo e salvá-lo em seu cache. Então, da próxima vez que houver uma consulta a este ativo, será usado o ativo armazenado no cache da CDN. Isso permite uma experiência mais dinâmica, como citado anteriormente.
Estratégia Push:
Nessa técnica, os arquivos são carregados no servidor CDN, portanto, a primeira solicitação será mais rápida, mas custará mais, porque você precisará pagar pelo armazenamento carregado. Uma técnica comum é usar domínios personalizados ao lidar com CDN. O que você precisa fazer é configurar sua CDN para acessar seu provedor de CDN. No momento de pagar por um certificado SSL, você poderia pagar por *.myapp para estar pronto para lidar com diferentes subdomínios, evitar problemas de CORS, e também atuar como balanceador manual de suas solicitações.
Atualização de conteúdo na CDN
Uma técnica comum para atualizar seu conteúdo na sua CDN é anexar um parâmetro de consulta ao seu ativo para criar uma versão dele, como por exemplo: cnd.myapp.com/scripts/app.js?version=1 neste caso, assim que precisar atualizar seus arquivos, você pode mudar a versão do ativo. Isso ajuda a criar uma abordagem de controle de versão (versionamento) automática ou automatizada, dependendo de como irá usá-la.
Dicas de design de API
Finalizando o post, vamos falar sobre APIs e quais são os padrões de comunicação entre o cliente e o back-end?
As APIs são um conjunto de padrões que fazem parte de uma interface e que permitem a criação de plataformas de maneira mais simples e prática para desenvolvedores. A partir de APIs é possível criar softwares, aplicativos, programas e plataformas diversas. Por exemplo, apps desenvolvidos para celulares Aindroid e IOS são criados a partir de padrões definidos e disponibilizados pelas APIs de cada sistema operacional. Existem diferentes estratégias e abordagens; e o cliente pode ser um navegador da web e IOS ou Andriod. E esses clientes podem ser comunicados ao back-end do seu servidor web.
O objetivo das APIs é tornar a experiência mais simples possível e uma maneira de ser simples e comum é fazer CRUDs. E aqui você encontra um conjunto de práticas recomendadas sobre APIs. Além disso, você precisa pensar sobre suas Entradas e Saídas, e como passar os parâmetros corretos para suas APIs. Lembre-se de usar sempre uma chave para autenticação segura, um mecanismo muito comum é usar tokens JWT. Outra consideração é decidir se o aplicativo será um driver cliente ou driver servidor. Por exemplo, se o APP for uma UX muito importante ou tenha necessidade crítica de desempenho, a aplicação precisa ser mais responsiva e haverá necessidade de desenvolvimento nativo para a plataforma desejada. As limitações incluem necessidade de duplicar o código lógico para cada nova aplicação nativa. Por exemplo, no caso de você precisar algo muito específico para Android, ou para IOS, etc. Além disso, outra limitação para o aplicativo móvel, é que geralmente um aplicativo de driver de servidor os recursos de memória e CPU são realmente limitados.
Outra consideração importante é dividir os pedidos de requisições ao servidor; por exemplo: poderíamos fazer um único pedido grande ao servidor e isso levaria vários milissegundos / segundos de resposta; ou podemos dividir esse pedido gigante em vários pedidos pequenos, para fazer um carregamento progressivo com melhor autonomia de resposta do servidor.
</>
