Criar um blog com Azure, Cosmos DB e Blazor WebAssembly

Criar um blog com Azure, Cosmos DB e Blazor WebAssembly

Olá! Com este artigo você aprenderá como criar seu blog no Azure Static Web junto com outros elementos de forma completa. Vou te mostrar os detalhes abaixo.

Tópicos que abordaremos


Arquitetura de software


• Azure.
• JAMstack, BLAMstack
• Azure Static Web Apps (aplicativos estáticos Web Azure).
• Azure Functions (funções Azure).
• Bancos de dados Cosmos DB.

Implementação do exemplo

• Um blog com Blazor Web Assembly.

Azure


Azure é a plataforma de nuvem da Microsoft. Ele fornece vários serviços, como Azure Static Web Apps, Azure Functions e Cosmos DB, entre outros.

JAMstack e BLAMstack


JAMstack é uma arquitetura de desenvolvimento web baseada na entrega de conteúdo estático por meio de um servidor de arquivos estático. JAM refere-se a JavaScript, APIs e Markup.

Em um aplicativo JAMstack, a interface do usuário é fornecida por uma página HTML estática que é entregue ao cliente. As interações dinâmicas do usuário (como enviar um formulário ou carregar dados atualizados) são tratadas pelo JavaScript, que é executado no cliente e faz solicitações a APIs externas para obter os dados necessários.

O uso do JAMstack traz vários benefícios, como melhor desempenho devido à entrega de conteúdo estático e maior segurança devido ao uso reduzido de servidores web tradicionais.

Como o backend atende apenas solicitações de dados em vez de páginas (como fazem os aplicativos tradicionais), podemos usar arquiteturas serverless, como Azure Functions ou AWS Lambda. Isso pode ajudar a reduzir os custos na nuvem.

Para este aplicativo, usarei o BLAMStack, que é o BlazorWebAssembly em vez de um framework JavaScript como React, Angular ou Vue para o frontend. O Blazor WebAssembly é executado da mesma forma que os aplicativos JAMStack executados na máquina do usuário, enquanto uma API fornece dados que tornam o aplicativo dinâmico. Podemos ver a diferença em aplicativos hospedados no servidor atualizando as páginas em nosso aplicativo. Nas tradicionais, ele retornará ao servidor para solicitar a página, baixar o conteúdo e exibi-lo. Em contraste, em um aplicativo SPA como o Blazor, o código do aplicativo executado no navegador é entregue e constrói a própria página.

Se atualizarmos a página, não estamos chamando o SPA, portanto a página não existe. Para evitar isso, usamos o backup de navegação e o configuramos no arquivo wwwroot staticwebapp.config.json.

Azure Static Web Apps


Introduzidos em 2021, eles fornecem os seguintes elementos necessários para implementar um JAMstack/BLAMStack:

• Hospedagem de arquivos estáticos para frontend (FE).
• Funções sem servidor para a API.
• Roteamento de componentes para conectar com segurança o FE e o back-end da API.
• Ele também fornece serviços como autenticação e CI/CD.
• Ele permite que você implante conteúdo estático na Web como front-end em conjunto com funções serverless como backend.

Isso permite a implementação da arquitetura de software mencionada acima, JAMstack (que significa JavaScript, API e Markup).

Essa arquitetura faz uso de arquivos de marcação e JavaScript para construir dinamicamente aplicativos que rodam no navegador e são plugados. obter ou gravar dados.

No nosso caso, usamos o Blazor como cliente, uma alternativa ao JavaScript e que permite que o código desenvolvido em C# seja executado no navegador. Alguns chamam essa modificação de BLAMstack.

Como o back-end atende apenas solicitações de dados, não de páginas, podemos fazer uso de arquiteturas de microsserviços, como as fornecidas pelo Azure Functions. Para Aplicativos Web Estáticos do Azure, apenas funções do Azure do tipo httptrigger podem ser usadas.

Podemos implementar essa arquitetura no Visual Studio para que tenhamos uma estrutura semelhante à da imagem:

Azure Functions


São soluções serverless que se concentram em funcionalidades específicas, como tratamento de eventos, alterações de banco de dados, tratamento de mensagens ou processamento de fluxo de dados IoT (Internet of Things).

Alguns equivalentes em outros provedores de serviços em nuvem são AWS Lambda, Google App Engine, entre outros. no caso dos Static Web Apps usamos Azure Functions dentro das funções dos serviços para que eles forneçam os serviços API. Abaixo podemos ver um exemplo do código de uma Azure Function.

Nesse caso, um que nos fornece um endpoint de API, que fornece a lista de postagens do blog:


Cosmos DB


É o banco de dados que usei no blog, do tipo NoSQL (bancos não relacionais que possuem estrutura e funcionamento diferenciados).

Em um banco de dados deste tipo temos variáveis ​​e documentos; a estrutura destes pode variar em que alguns dos dados podem ou não estar presentes. Assim, em alguns dos elementos do nosso blog poderão existir imagens e noutros não, pelo que haveria necessidade de adicioná-los apenas naqueles em que for necessário.

Embora sejam classificados como NoSQL, estas bases de dados permitem a utilização da linguagem SQL para consultar os bancos de dados (como vimos no exemplo de código das functions).

Neste caso, criamos um banco de dados onde adicionamos partições e contêineres. É importante mencionar que os bancos de dados podem ser implantados e acessá-los globalmente.


Exemplo que implementamos


Usamos o Blazor WebAssembly como parte do cliente. FrontEnd e Azure Funcionam como API Backend. Ambos estão hospedados no Azure Static Web App.

  • O Blazor WebAssembly pode ser implantado como arquivos estáticos no Azure Static Web App.
  • Contém código de front-end. O aplicativo é inicializado em Program.cs. A partir dos componentes do Razor também podemos injetar os serviços.
  • Finalmente, o aplicativo WebAssembly é construído e executado.
  • No archive _Imports.razor podemos adicionar e unificar as referências a arquivos e bibliotecas que usaríamos dos diferentes componentes do aplicativo cliente Blazor.
  • App.razor carrega o roteador para o aplicativo que contém os componentes e permite que eles sejam carregados (a partir de um link, por exemplo). Ele também manipula as rotas quando elas são encontradas.
  • A pasta Wwwroot é aquela utilizada para publicar a aplicação quando utilizamos o WebAssembly e onde se encontram os arquivos estáticos da parte cliente. Aqui, Index.html é o ponto de entrada do aplicativo toda vez que o aplicativo é carregado pelo navegador.
  • Na pasta Shared encontramos o MainLayout.razor, utilizado como modelo ou gabarito para as páginas, e o NavMenu.razor, que fornece o menu de navegação e é carregado no MainLayout.
  • Na pasta Pages temos o Index.razor, página raiz da aplicação.

Azure Functions – API Backend

  • Em Static Web Apps, só pode ser usado Http-Triggered functions can be used with.
  • Dentro do Projeto API temos o Azure Functions. Eles representam os endpoints HTTP que retornam respostas (responses).

Cosmos DB – DB

  • Implementamos esse banco de dados na configuração (settings) do Static Web App.
  • Configuramos a Connection String na API. Por exemplo, configurações locais não incluídas no Git para teste local no aplicativo Web estático no Azure para produção.

Configuração de Custom Domain

Pronto! Desta forma, criamos nosso blog com os elementos mencionados. Espero que este guia tenha sido útil. Vejo você na próxima oportunidade.

Saudações

Referências

💡
As opiniões e comentários expressos neste artigo são de propriedade exclusiva de seu autor e não representam necessariamente o ponto de vista da Revelo.

A Revelo Content Network acolhe todas as raças, etnias, nacionalidades, credos, gêneros, orientações, pontos de vista e ideologias, desde que promovam diversidade, equidade, inclusão e crescimento na carreira dos profissionais de tecnologia.