home

Blazor

Fontes:

Table of contents

Conceitos

Latência (Latency)

No desenvolvimento de software web, latência se refere ao tempo decorrido entre a ação de um usuário e a resposta do servidor. Essencialmente, é o tempo que os dados levam para viajar da fonte (como o navegador de um usuário) para o destino (como um servidor web) e voltar novamente.

Por exemplo, quando você clica em um link em uma página web, latência é o tempo que o servidor leva para processar essa solicitação e enviar os dados necessários de volta para o seu navegador. Menor latência significa tempos de resposta mais rápidos, o que é crucial para uma boa experiência de usuário.

Throughput

No desenvolvimento de software web, throughput se refere à quantidade de dados ou número de transações que um sistema pode processar dentro de um período específico. É uma medida de quanto trabalho pode ser concluído em um determinado período de tempo, geralmente expresso em termos de solicitações por segundo, transações por segundo ou bits/bytes por segundo.

Por exemplo, se um aplicativo web pode lidar com 100 solicitações por segundo, seu throughput é de 100 solicitações por segundo. Um alto throughput indica que o sistema pode processar um grande número de transações rapidamente, o que é crucial para desempenho e escalabilidade.

Motivação para usar Blazor

Blazor surgiu como uma alternativa ao uso de JavaScript e seus frameworks (React, Angular, Vue, etc) em SPAs. A idea é conseguir criar aplicações web responsivas apenas utilizando C#.

De outra forma, deixa de ser necessário aprender várias das tecnologias envolvidas na Web, utilizando apenas a linguagem que desenvolvedores C# já conhecem.

O que é Blazor

Blazor é um Framework de UI open-source no qual você pode criar aplicativos web interativos usando HTML, CSS e C# com suporte total para bindings, eventos, formulários e validação, injeção de dependência, depuração e muito mais.

Diferentes maneiras de rodar Blazor

Blazor Server

O Blazor Server usa o SignalR para comunicação entre o cliente e o servidor, conforme mostrado no diagrama a seguir:

Overview Blazor Server

SignalR é uma biblioteca de comunicação em tempo real que cria uma conexão entre o cliente e o servidor. O SignalR pode usar muitos meios diferentes de transporte de dados e seleciona automaticamente o melhor protocolo de transporte com base nas capacidades do seu servidor e cliente. O SignalR sempre tentará usar WebSockets, que é um protocolo de transporte integrado ao HTML5. Se o WebSockets não estiver habilitado, ele selecionará outro protocolo.

O Blazor é criado com elementos de UI reutilizáveis ​​chamados componentes. Cada componente contém código C# e marcação. Um componente pode incluir outros componentes. Você pode usar a sintaxe Razor para misturar marcação e código C# ou fazer tudo em C#, se desejar. Os componentes podem ser atualizados pela interação do usuário (pressionando um botão) ou gatilhos (como um cronômetro).

Os componentes são renderizados em uma árvore de renderização, uma representação binária do DOM contendo estados de objetos e quaisquer propriedades ou valores. A árvore de renderização manterá o controle de quaisquer alterações em comparação com a árvore de renderização anterior e, em seguida, enviará apenas as coisas que mudaram no SignalR usando um formato binário para atualizar o DOM.

O JavaScript receberá as alterações no lado do cliente e atualizará a página de acordo. Se compararmos isso ao ASP.NET tradicional, renderizamos apenas o componente em si, não a página inteira, e enviamos apenas as alterações reais para o DOM, não a página inteira.

Existem vantagens no Blazor Server:

Existem, é claro, algumas desvantagens no Blazor Server também:

Blazor WebAssembly

O runtime Mono é uma ferramenta que permite que você execute programas feitos com C# e outras linguagens .NET em vários sistemas operacionais, não apenas Windows.

A Microsoft pegou o runtime Mono (que é escrito em C) e o compilou no WebAssembly.

A versão WebAssembly do Blazor funciona de forma muito similar à versão do servidor, como mostrado no diagrama a seguir. Movemos tudo para fora do servidor, e agora está rodando dentro do nosso navegador da web:

Overview Blazor WebAssembly

Uma árvore de renderização ainda é criada e, em vez de executar as páginas do Razor no servidor, elas agora estão sendo executadas dentro do nosso navegador da web. Em vez do SignalR, como o WebAssembly não tem acesso direto ao DOM, o Blazor atualiza o DOM com interoperabilidade direta de JavaScript.

O runtime do Mono que é compilado no WebAssembly é chamado dotnet.wasm. A página contém um pequeno pedaço de JavaScript que garantirá o carregamento do dotnet.wasm. Em seguida, ele baixará o blazor.boot.json, um arquivo JSON contendo todos os arquivos que o aplicativo precisa para ser executado, bem como o ponto de entrada do aplicativo.

Se olharmos para o site de amostra padrão que é criado quando iniciamos um novo projeto Blazor no Visual Studio, o arquivo Blazor.boot.json contém 63 dependências que precisam ser baixadas. Todas as dependências são baixadas e o aplicativo inicializa.

Como mencionamos anteriormente, dotnet.wasm é o runtime do mono que é compilado no WebAssembly. Ele roda DLLs .NET – aquelas que você escreveu e as do .NET Framework (que são necessárias para rodar seu aplicativo) – no seu navegador.

Parece exagerado rodar todo o runtime do .NET no meu navegador, mas por outro lado você pode rodar qualquer DLL .NET Standard no seu navegador.

Vantagens do Blazor WebAssembly:

Desvantagens no Blazor WebAssembly:

SSR (Server-Side Rendering)

A renderização do lado do servidor é a novata no bloco Blazor. Ela torna possível usar a sintaxe Razor para construir páginas da web que são renderizadas do lado do servidor, assim como MVC ou Razor Pages. Isso é chamado de renderização estática do lado do servidor. Ela tem alguns recursos adicionais que continuarão rolando na posição anterior, mesmo que a página inteira seja recarregada, o que é chamado de navegação de formulário aprimorada. Isso renderizará apenas páginas estáticas, sem interatividade (com algumas exceções). Há também algo chamado renderização de streaming que carregará a página ainda mais rápido. Este modo é chamado de renderização do lado do servidor de streaming. Durante tarefas de longa duração, a renderização de streaming primeiro enviará o HTML que possui e, em seguida, atualizará o DOM assim que a tarefa de longa duração for concluída, dando a ela uma sensação mais interativa.

Trabalhando com os 3 tipos de uma só vez

Podemos escolher quais componentes serão executados usando SSR e quais componentes usarão Blazor Server, Blazor WebAssembly ou uma mistura dos dois.

Anteriormente, tínhamos que escolher um dos dois (Blazor Server ou Blazor WebAssembly), mas agora podemos combinar as tecnologias para obter o melhor dos dois mundos. Agora podemos dizer a cada componente como queremos que ele seja renderizado e podemos misturar e combinar em todo o site. O novo recurso “auto” significa que na primeira vez que nossos usuários visitarem o site, eles executarão o Blazor Server. Isso é para obter uma conexão rápida e obter dados para o usuário o mais rápido possível. Em segundo plano, a versão do WebAssembly é baixada e armazenada em cache para que, na próxima vez que visitarem o site, ele use a versão do Blazor WebAssembly em cache. Se a versão do WebAssembly puder ser baixada e iniciada em 100 milissegundos, ela carregará apenas a versão do WebAssembly. Se demorar mais, ele iniciará o Blazor Server e fará o download em segundo plano.

Esta é uma das maneiras pelas quais podemos acelerar a velocidade de download do nosso site Blazor. Podemos combinar todas essas tecnologias, pré-renderizar o conteúdo no servidor usando o Static Server-side Rendering, tornar o site interativo usando Blazor Server (usando SignalR) e, em seguida, alternar para o Blazor WebAssembly sem o “longo” tempo de download.

Opções durante a criação de um projeto em Blazor

O template Blazor Web App (blazor) nos dá um aplicativo Blazor.

Depois de selecionar esse template, obtemos opções:

Se adicionarmos páginas de amostra, obtemos alguns componentes para ver a aparência de um aplicativo Blazor e alguma configuração básica e estrutura de menu. Ele também contém código para adicionar Bootstrap, CSS isolado e coisas assim.

O template Blazor WebAssembly Standalone App (blazorwasm) nos dá (como o nome indica) um aplicativo Blazor WebAssembly autônomo. Aqui, podemos escolher:

Então por que temos este? Bem, o Blazor Web App depende de tecnologias de renderização de servidor de uma forma ou de outra. Se você quiser executar seu aplicativo a partir de um compartilhamento de arquivos, GitHub Pages ou Azure Static Web Apps (para citar alguns), este é o modelo para você.

Linha de comando

A linha de comando abaixo cria um projeto Blazor configurado para suportar tanto Blazor Server quanto Blazor WebAssembly e as páginas usarão a renderização estática do servidor por padrão e podem ser marcadas como interativas por página ou por componente.

dotnet new blazor --name BlazorWebApp --output MyBlog --framework net8.0 --interactivity Auto --auth None --all-interactive false

Sequência de execução de uma aplicação Blazor

Essa é a sequência de execução dos arquivos em uma aplicação Blazor:

Arquivo Responsabilidade
Program.cs (BlazorWebApp project) É a primeira classe a ser chamada e é a responsável por montar a pipeline de middlewares para as requisições que o app receberá.
Program.cs (BlazorWebApp.Client) Esse não faz muito. Ele simplesmente configura um construtor de host e usa a configuração padrão para permitir que o app funcione com WebAssembly no client.
App (BlazorWebApp) O componente app.razor é o próximo a executar.
Routes é o componente acionado de dentro do App (BlazorWebApp) e vai definir o esquema de rotas para o app. Inclusive vai definir o layout default para cada rota.
MainLayout contém o layout padrão para todos os componentes quando visualizados como uma página.
NavMenu é o componente acionado de dentro do MainLayout. Ele contém o menu do lado esquerdo e é um menu padrão do Bootstrap.
NavLink esse componente é construído no framework. Ele renderizará uma tag de âncora, mas também verificará a rota atual. Se você estiver atualmente na mesma rota/URL que o link de navegação, ele adicionará automaticamente uma classe CSS chamada active à tag.

Projetos criados pelo template

Componentes

No Blazor, um componente é um arquivo .razor que contém uma funcionalidade pequena e isolada (código e marcação) ou pode ser usado como uma página.

Existem três maneiras diferentes de criar um componente:

Diretiva @page

@page "/counter"

Torna possível rotear diretamente para o componente

Diretiva @rendermode

@rendermode InteractiveAuto

Esta é a maneira como podemos definir o modo de renderização em um componente específico. Isso significa que quando usamos este componente, ele primeiro renderizará a página usando o Blazor Server (com SignalR) e, em segundo plano, baixará a versão do WebAssembly para que, na próxima vez que carregarmos a página, ele execute a versão do WebAssembly.

Declaração @code

@code {
  private int currentCount = 0;
  private void IncrementCount()
  {
    currentCount++;
  }
}

Permite adicionar código C# ao componente. Para acessar o valor armazenado em currentCount basta usar o @.

<p role="status">Current count: @currentCount</p>

Para acessar o método IncrementCount também basta usar o @.

<button class="btn btn-primary" @onclick="IncrementCount">Click me</ button>

Se usássemos onclick sem o @, ele se referiria ao evento JavaScript e não funcionaria.