Criando um CRUD com Blazor WASM + Minimal APIs (Parte 2)

Porta da API

O conteúdo do arquivo da API se parece com o trecho abaixo. Repare na propriedade applicationUrl.

// BlzCrs.Backend/Properties/launchSettings.json
"profiles": {
    "http": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "http://localhost:5258",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },

Nesse perfil, a porta da API do nosso CRUD com Blazor WASM é a 5258. Anote esse número, porque vamos usá-lo no frontend.

As portas variam de máquina para máquina, já que o template sorteia os valores ao criar o projeto. Então, sempre confira o seu próprio arquivo.

Porta do frontend

Da mesma forma, anote a porta da aplicação que vai rodar o nosso app Blazor WebAssembly.

// BlzCrs.Frontend/Properties/launchSettings.json
"http": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
      "applicationUrl": "http://localhost:5293",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },

Aqui, o frontend roda na porta 5293. Além disso, a propriedade inspectUri habilita a depuração do código WebAssembly pelo navegador.

Com as duas portas em mãos, já sabemos para onde o frontend precisa enviar as requisições e qual origem a API precisa liberar.

Classe de configuração

Para começar, criamos duas configurações no frontend. A primeira serve como nome do cliente HTTP e a segunda guarda a URL do backend obtida no passo anterior.

public class Configuration
{
    public static string HttpClientName = "backend";
    public static string BackendUrl = "http://localhost:5258";
}

Centralizar esses valores evita espalhar textos fixos pelo código. Assim, quando a URL mudar, alteramos um único lugar.

Em produção, o ideal é ler a URL de um arquivo de configuração, como o wwwroot/appsettings.json. Para este exemplo, a classe estática atende bem.

Lendo a URL do appsettings.json

Se preferir não fixar a URL no código, o Blazor WebAssembly lê automaticamente o arquivo wwwroot/appsettings.json ao iniciar.

{
  "BackendUrl": "http://localhost:5258"
}

Em seguida, basta ler o valor pelo builder.Configuration no Program.cs do frontend.

// lê a URL do backend e usa um valor padrão caso a chave não exista
var backendUrl = builder.Configuration["BackendUrl"] ?? "http://localhost:5258";

Atenção: o navegador baixa esse arquivo junto com o app. Portanto, nunca coloque segredos, como senhas ou chaves de API, no appsettings.json de um projeto WebAssembly.

Pacote Microsoft.Extensions.Http

Com as configurações criadas, instalamos o pacote Microsoft.Extensions.Http. Ele traz o IHttpClientFactory e funcionalidades adicionais ao pacote HTTP padrão do .NET.

dotnet add package Microsoft.Extensions.Http

De acordo com a documentação sobre chamadas de API no Blazor, esse pacote habilita clientes nomeados e tipados dentro de um app WebAssembly.

Registrando o HttpClient

Com tudo pronto, registramos um HttpClient nomeado no arquivo Program.cs do frontend.

builder.Services.AddHttpClient(
    Configuration.HttpClientName,
    opt => opt.BaseAddress = new Uri(Configuration.BackendUrl));

O primeiro argumento é o nome do cliente. Já o segundo define o endereço base, então as chamadas seguintes só precisam informar o caminho relativo, como v1/categories.

O cliente nomeado é útil quando a aplicação conversa com mais de uma API. Afinal, cada uma pode ter seu próprio nome, endereço e cabeçalhos.

Cliente tipado como alternativa

A documentação também apresenta o cliente tipado. Nesse modelo, o serviço recebe um HttpClient já configurado, sem precisar chamar o CreateClient.

// registra o serviço como cliente tipado, com o endereço base da API
builder.Services.AddHttpClient<CategoryService>(
    client => client.BaseAddress = new Uri(Configuration.BackendUrl));

Com isso, o construtor do serviço passaria a receber um HttpClient diretamente. Ambas as abordagens funcionam, então escolha a que deixar o código mais claro para o seu time.

Neste guia, seguimos com o cliente nomeado, que mantém o mesmo padrão usado no vídeo.

Registrando o serviço no CRUD com Blazor WASM

Para injetar o serviço nas páginas do CRUD com Blazor WASM, também precisamos registrá-lo no container de dependências do Program.cs.

builder.Services.AddScoped<CategoryService>();

No WebAssembly, o escopo Scoped se comporta praticamente como Singleton, já que existe uma única instância do app por aba do navegador.

Injetando o serviço

Para usar o serviço na página, primeiro precisamos injetá-lo com a diretiva @inject.

@page "/"
@using BlzCrd.Frontend.Models
@using BlzCrd.Frontend.Services
@inject CategoryService CategoryService

A diretiva @page define a rota da página. Já o @inject pede ao container uma instância do CategoryService e a expõe com o mesmo nome.

Utilizando o serviço

O código da implementação fica bem simples, bastando chamar o serviço injetado.

@code {
    private List<Category> _categories = new();

    private async Task ListAsync()
    {
        _categories = await CategoryService.GetAsync();
    }

    private async Task CreateAsync()
    {
        var category = new Category
        {
            Id = 0,
            Title = "New category",
            Description = "Category description"
        };
        await CategoryService.CreateAsync(category);
    }
}

O método ListAsync busca as categorias e guarda o resultado no campo _categories. Então, o Blazor renderiza a página de novo após o evento.

Já o CreateAsync monta uma categoria de exemplo e envia para a API. O Id vale zero porque o banco gera o valor definitivo.

Montando a interface

Por fim, o HTML fica ainda mais simples. Ele percorre a lista de categorias e oferece um botão para criar e outro para listar.

<PageTitle>Home</PageTitle>

<h1>Categories</h1>

<ul>
    @foreach (var item in _categories)
    {
        <li>@item.Title</li>
    }
</ul>

<button class="btn btn-primary" @onclick="CreateAsync">
    Create
</button>

<button class="btn btn-primary" @onclick="ListAsync">
    List
</button>

O @onclick liga cada botão ao método correspondente. Como os dois métodos retornam Task, o Blazor aguarda a conclusão e atualiza a tela em seguida.

Se você quiser carregar a lista assim que a página abrir, basta chamar o ListAsync dentro do OnInitializedAsync.

@code {
    // carrega as categorias assim que o componente inicializa
    protected override async Task OnInitializedAsync()
    {
        await ListAsync();
    }
}

Também é uma boa ideia exibir um aviso de carregamento enquanto a requisição não termina. Para isso, um campo booleano como _isLoading resolve o problema com poucas linhas.

O que é CORS

CORS significa Cross-Origin Resource Sharing. Trata-se de um mecanismo do navegador que bloqueia chamadas entre origens diferentes, a menos que o servidor autorize.

Uma origem combina esquema, domínio e porta. Por isso, http://localhost:5293 e http://localhost:5258 são origens diferentes, mesmo rodando na mesma máquina.

Como o código do CRUD com Blazor WASM executa no navegador, ele está sujeito a essa regra. Em contrapartida, uma chamada feita de servidor para servidor não passa por essa verificação.

Além disso, um POST com corpo JSON dispara uma requisição de preflight do tipo OPTIONS. Nela, o navegador pergunta à API se aceita o método e os cabeçalhos antes de enviar os dados.

Configurando a política na API

Para habilitar o CORS entre o app e a API, fazemos três ajustes no backend. Primeiro, criamos uma classe de configuração.

namespace BlzCrd.Backend;

public static class Configuration
{
    public static string CorsPolicyName = "wasm";
    public static string BackendUrl = "http://localhost:5258";
    public static string FrontendUrl = "http://localhost:5293";
}

Em seguida, configuramos uma política de CORS logo após o registro do SQLite.

// ...
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<AppDbContext>(x => { x.UseSqlite("DataSource=app.db;Cache=Shared"); });
builder.Services.AddCors(
    options => options.AddPolicy(
        Configuration.CorsPolicyName,
        policy => policy
            .WithOrigins([Configuration.BackendUrl, Configuration.FrontendUrl])
            .AllowAnyMethod()
            .AllowAnyHeader()
            .AllowCredentials()));

var app = builder.Build();
// ...

O WithOrigins lista as origens permitidas. Na prática, a origem que realmente importa aqui é a do frontend, já que é ele quem chama a API pelo navegador.

O AllowAnyMethod e o AllowAnyHeader liberam todos os verbos e cabeçalhos. Já o AllowCredentials permite enviar cookies e credenciais nas requisições.

Vale um cuidado: o ASP.NET Core não aceita combinar AllowAnyOrigin com AllowCredentials. Por isso, listar as origens explicitamente é o caminho correto.

Aplicando a política

Por fim, usamos a política criada para liberar o acesso do frontend à API.

// ...
var app = builder.Build();

app.UseCors(Configuration.CorsPolicyName);

app.MapGet("/", () => "Hello World!");
// ...

O UseCors precisa vir antes do mapeamento dos endpoints. Assim, o middleware adiciona os cabeçalhos corretos em todas as respostas, inclusive no preflight.

A documentação oficial de CORS no ASP.NET Core detalha outras opções, como políticas por endpoint com RequireCors.

Agora, execute a API e o frontend ao mesmo tempo. Ao clicar em Create e depois em List, a nova categoria aparece na tela.