admin 
[ad_1]
As soluções sem servidor estão capacitando pequenas equipes a fazer mais e se concentrar em seus negócios. Um dos princípios do desenvolvimento de software é manter as coisas SECO, ou “Não se repita”. Software as a Service (SaaS) é uma iteração desse princípio com benefícios adicionais. Ao migrar para infraestruturas sem servidor gerenciadas, as equipes de engenharia podem reduzir o gerenciamento operacional, permitindo mais tempo para o desenvolvimento do produto.
As infraestruturas sem servidor fornecem dimensionamento sob demanda para crescer com as necessidades de negócios e os sistemas distribuídos reduzem a latência de rede para os usuários. Esses elementos trabalham juntos para criar experiências superiores para o usuário final, pois a empresa pode se concentrar no produto, tem dimensionamento automatizado e está entregando conteúdo da região do usuário. Os clientes estão solicitando arquiteturas sem servidor para criar escalabilidade e longevidade com custos reduzidos. As soluções compostas aumentam a velocidade de desenvolvimento, aumentando assim os resultados de negócios enquanto encantam desenvolvedores e usuários finais.
Considerações arquitetônicas
Ao tomar decisões de arquitetura, os engenheiros também precisam considerar os impactos no desempenho. Dada a natureza sob demanda das arquiteturas sem servidor, os engenheiros precisam considerar os tempos de inicialização a frio à medida que os recursos estão sendo provisionados, processos de longa execução que excedem os limites de tempo de execução sem servidor, sobrecarga de rede de solicitações a recursos externos e a possibilidade de dependência do fornecedor. Dependendo das necessidades e do uso de um aplicativo, um servidor dedicado pode ser mais barato ou mais eficiente para parte ou toda a infraestrutura. Ao tomar essas decisões, considere quem usa o aplicativo, onde eles estão localizados e como essas compensações afetam as necessidades de negócios.
Necessidades comuns de aplicação
Construir e implantar um aplicativo da Web normalmente requer um host para servir o código do aplicativo, autenticação para permitir que os usuários entrem no sistema e um banco de dados para armazenar e recuperar dados. No domínio sem servidor, os arquivos estáticos da etapa de construção do aplicativo são frequentemente implantados em uma CDN para fornecer alta disponibilidade aos usuários; o código do aplicativo que precisa ser executado em um ambiente de servidor pode ser implementado em funções sem servidor que são executadas sob demanda. A autenticação de um usuário pode ser resolvida integrando um provedor de identidade (IdP) para gerenciar usuários, fornecer fluxos de login e retornar um token de acesso para a sessão de um usuário. Os bancos de dados sem servidor substituem a necessidade de hospedagem e dimensionamento de uma solução de armazenamento de dados.
A partir desta base, soluções adicionais que podem ser compostas podem ser integradas para adicionar funcionalidade. Isso pode incluir soluções sem servidor para trabalhos em segundo plano de longa duração ou trabalhos cron agendados, execução de testes para integração contínua, otimização de imagens ou vídeo, gerenciamento de conteúdo, implementação de um mecanismo de pesquisa, processamento de pagamentos, geocodificação, soquetes da Web ou outros serviços. O que esses elementos têm em comum é o fato de que todas elas são APIs que podem ser compostas e trabalhar juntas para fornecer experiências ricas ao usuário, ao mesmo tempo que facilitam a sobrecarga de desenvolvimento e colocam um produto no mercado mais cedo.
A criação de um aplicativo da Web totalmente composto acabará parecendo uma malha de chamadas de API para sistemas externos, que combinam resultados para implementar suas necessidades de negócios. As próximas seções irão mergulhar em tecnologias específicas que podem ser usadas para implementar diferentes partes do seu sistema. Embora existam muitas opções para escolher, nesta postagem do blog, focarei nas tecnologias que uso regularmente.
Como implantar ativos estáticos em uma rede de entrega de conteúdo (CDN)
Se você estiver criando um site puramente estático, sua etapa de criação produzirá um conjunto de arquivos estáticos que podem ser implantados em uma rede de entrega de conteúdo (CDN). Ao contrário de um servidor centralizado, o conteúdo de uma CDN é distribuído em todo o mundo. Isso significa que o conteúdo é entregue a um usuário a partir do nó mais próximo da rede, aumentando assim a velocidade de entrega ao usuário. Se você estiver criando um aplicativo de página única (SPA), ainda terá ativos estáticos que podem ser implantados em uma CDN, permitindo que seu aplicativo também seja entregue aos usuários pelo nó de rede mais próximo. Uma das soluções que a Netlify oferece é implantar seus ativos estáticos em uma CDN para você automaticamente. Depois que o Netlify executa seu comando de compilação, os ativos em seu diretório de compilação são implantados na CDN do Netlify. Para obter uma introdução mais detalhada ao Netlify, consulte Introdução ao Netlify: Criando seu primeiro site Netlify.
Criando uma API com funções sem servidor
Se você estiver criando um SPA ou uma API sem front-end, precisará de um lugar para executar esse código. Em aplicativos baseados em servidor, sua API seria executada em seu(s) servidor(es) e seria limitada aos recursos desse hardware. Você é responsável por gerenciar e dimensionar os servidores para atender à demanda. Como o servidor está sempre ligado, isso significa que também há momentos em que os recursos são subutilizados. As funções sem servidor fornecem uma solução sob demanda para executar seu código e implementar uma API que não exige que você gerencie ou dimensione servidores. O Netlify Functions implanta perfeitamente seus endpoints de API no AWS Lambdas durante a etapa de compilação, permitindo que sua API seja dimensionada de acordo com a demanda do usuário.
Fornecendo autenticação com um provedor de identidade (IdP)
Se o site que você está criando exigir usuários distintos, você precisará de uma maneira de gerenciar e autenticar esses usuários. Um provedor de identidade (IdP) fornece autenticação como um serviço. Auth0 é um Provedor de Identidade que fornece fluxos de login para seu aplicativo e retorna um token de acesso para o usuário autenticado. O token de acesso pode então ser incluído no Authorization header ao fazer solicitações para suas funções sem servidor e verificadas por sua API.
Fornecendo dados dinâmicos com um banco de dados sem servidor
Um requisito central da maioria dos aplicativos é a persistência dos dados do usuário em um banco de dados. Os bancos de dados tendem a ser um gargalo e são difíceis de dimensionar se você os estiver gerenciando por conta própria com um banco de dados centralizado. Se vários usuários estiverem tentando gravar no mesmo registro de banco de dados, você poderá encontrar um impasse enquanto cada solicitação estiver aguardando a outra para desistir do bloqueio, impedindo que seus usuários usem o sistema. À medida que seu banco de dados cresce, você precisará fragmentar ou particionar seus dados, o que tornará mais desafiador manter o banco de dados consistente, bem como consultar os dados em instâncias de banco de dados.
Um dos desafios dos bancos de dados sem servidor é a troca entre consistência e disponibilidade. Muitos bancos de dados sem servidor sofrem de consistência eventual, o que significa que os usuários nem sempre podem obter a versão atual dos dados. Eventuais erros de consistência podem levar a mais complexidade no nível do aplicativo e aumentar a confusão e a frustração do usuário. Felizmente, há um banco de dados sem servidor que permanece compatível com ACID – ou seja, para ter a presença de atomicidade, consistência, isolamento e durabilidade – e fornece consistência forte, e esse é o Fauna.
Fauna é um banco de dados sem servidor exclusivo que permite implementar dados relacionais em um armazenamento de dados de documentos sem esquema, mantendo-se compatível com ACID, fornecendo consistência forte, consultas temporais, funções definidas pelo usuário, funções definidas pelo usuário e uma integração de provedor de acesso com provedores de identidade como Aut0. Ao integrar com o Provedor de Acesso do Fauna você pode usar o token de acesso do Auth0 para consultar o Fauna como aquele usuário. Saiba mais sobre as ofertas exclusivas do Fauna lendo esta introdução ao FaunaDB e FQL.
E quanto a lidar com tarefas cron e processos de longa duração?
As funções sem servidor nem sempre são suficientes para suas necessidades. Às vezes, você precisa executar um código que leva mais do que os 10 segundos normalmente atribuídos às funções sem servidor ou precisa executar uma tarefa em um agendamento, como um trabalho cron. O GitHub Actions é uma ótima opção se você já estiver usando o GitHub e precisar dessa funcionalidade. Atualmente, estou usando o GitHub Actions para implementar tarefas cron e processar webhooks de longa duração em segundo plano. A Netlify oferece funções em segundo plano como um recurso beta e funções agendadas recentemente adicionadas como um recurso experimental. Eu não usei essas opções mais recentes do Netlify, mas estou animado para experimentá-las e espero que elas estejam prontas para produção.
Integração contínua
A última peça que a maioria dos projetos precisa é uma solução de Integração Contínua (CI). O GitHub Actions também se encaixa bem aqui, supondo que você já esteja usando o GitHub para seu projeto. Como o GitHub Actions é um produto do GitHub, é fácil acionar seu fluxo de trabalho de CI de git eventos como um pull_request ou um push. Configurando uma ação do GitHub para ser executada em um pull_request também incluirá automaticamente o fluxo de trabalho de CI no Checks seção do seu pull request.
O que mais você precisa?
A partir daqui, suas necessidades de aplicativo provavelmente serão mais variáveis com base no projeto. Vou destacar os serviços adicionais que usei ou estou de olho para abordar as soluções adicionais que você precisava, mas lembre-se de que geralmente há muitas opções para escolher e você deve escolher a solução que atenda às suas necessidades.
- Cloudinary fornece APIs para otimizar suas imagens e vídeos para entrega em diferentes dispositivos.
- Contentful é um sistema de gerenciamento de conteúdo rico que permite definir modelos e possui suporte integrado para internacionalização.
- O Algolia Search facilita a criação de um mecanismo de pesquisa personalizado para o seu conteúdo.
- O Stripe fornece APIs para integrar soluções de processamento de pagamentos.
- As APIs do AWS WebSocket no Amazon API Gateway fornecem soquetes da web como um serviço.
- A HERE fornece geocodificação e outras APIs relacionadas a mapas.
- Plaid fornece acesso a dados financeiros conectando contas bancárias.
Mantendo-o seco com módulos compartilhados
Você pode estar duplicando código em Funções do Netlify, GitHub Actions, seu front-end e/ou outras partes de sua pilha composta. Para mitigar isso, sugiro criar um módulo compartilhado que possa ser usado pelas várias partes do sistema. Pode não ser óbvio o que é necessário em um módulo compartilhado quando você está começando, mas se você começar a se repetir, anote a oportunidade de refatorar essa funcionalidade para um módulo compartilhado.
Uma maneira de criar um módulo compartilhado é em um repositório separado. Isso é particularmente útil se você precisar compartilhar este módulo em vários aplicativos. No entanto, ter o módulo compartilhado em outro repositório pode prejudicar seu fluxo de trabalho de desenvolvimento, especialmente nos estágios iniciais. Eu gosto de começar com um módulo compartilhado local com uma visão mais longa de movê-lo para um repositório separado, uma vez que esteja maduro o suficiente para fazê-lo. Nos estágios iniciais, é conveniente ter um módulo local que não exija gerenciamento adicional. Como tal, eu gosto de aproveitar package.json para instalar um módulo local com algo como "core": "file:./core" dentro dependencies. Eu gosto de manter a lógica de negócios e outros utilitários funcionais em um módulo compartilhado como este. Apenas tenha em mente que as necessidades de cada projeto são únicas e você precisará decidir o que faz sentido para o seu projeto. Explore o repositório inicial vinculado abaixo para ver como isso pode ser usado.
Considerações de front-end
Da mesma forma, no front-end, defendo há muito tempo o uso de Web Components, pois eles podem ser compostos e agora têm suporte à interoperabilidade em muitas estruturas de front-end. De uma perspectiva de composição, acho que a construção de componentes como componentes da Web oferece mais flexibilidade. Para obter contexto adicional, leia Construindo um Sistema de Design e Consumindo-o em Várias Estruturas usando Stencil.js.
Para começar com Netlify, Fauna, GitHub Actions, Stencil e um módulo compartilhado local, criei um repositório inicial como um exemplo para construir. O Starter Repository é a base de código que será implantada no Netlify usando o Deploy to Netlify botão. O Site Demo é um exemplo do Site Netlify que será implantado.
Siga as instruções no Repositório inicial Leia-me para as etapas adicionais necessárias para criar um banco de dados Fauna com dados de demonstração, gerar uma Chave de Servidor Fauna e configurar uma Variável de Ambiente no Netlify com sua Chave de Servidor Fauna.
Se você já possui contas Fauna e Netlify, um banco de dados Fauna com dados de amostra e uma chave de servidor Fauna, você pode clicar no botão Deploy to Netlify botão abaixo para começar.
Richard Flosi
Autor
Rancho Grande Nerd
[ad_2]
Source link
