blazorpost

Conforme informado na seção de Sobre, previamente à construção do projeto piloto, foi construído um boilerplate. Um boilerplate é nada mais que um modelo de solução que ajuda a criar aplicativos web rápidos, robustos e adaptáveis.

O boilerplate blazorpost além de já trazer organizado e configurado todos os componentes detalhados na stack de desenvolvimento traz integrado um layout rico responsivo construído sobre o framework Bootstrap, o Spark e os componentes do Bootstrap Blazor UI.

Fig. 1 - Tela do boilerplate blazorpost com o layout Spark.

Este foi configurado com as seguintes tecnologias:

Plataforma .NET 10 utilizando Blazor Server;
SGBD PostgreSQL (dados da aplicação);
MongoDB — integração somente leitura com os dados corporativos do ETL (unidades, empregados, pessoas, localidades), via os gateways institucionais (acessível apenas na rede da Sede; fora dela, ver o item 8 do FAQ);
Autenticação via Keycloak (OIDC), com suporte a login institucional, revinculação de contas migradas do antigo Google OAuth e autocadastro de usuários externos;
Autorização baseada em permissões sobre o ASP.NET Core Identity;
Arquitetura modular: solution multi-projeto (host + Core + Integracoes) com módulos de negócio em Razor Class Library;
Biblioteca de componentes visuais Bootstrap Blazor;
Layout configurado com o template Spark do Bootstrap, incluindo dashboard inicial com indicadores, busca na sidebar, central de notificações, layout compartilhado de login e modal de aviso de expiração de sessão;
Tratamento de exceção;
Localização e globalização (pt-BR, en-US, es);
Log;
Rastreamento de erros (via Sentry);
Rastreamento de uso e acessos (via Matomo);
Configurações para conteinerização.

ATENÇÃO: Por questões relacionadas ao licenciamento do layout Spark o boilerplate blazorpost só pode ser utilizado no desenvolvimento de soluções corporativas da Embrapa e soluções que não sejam “Comerciais” e/ou envolvam subscrição, assinatura, ou qualquer outro tipo de cobrança de produtos e/ou serviços para usuários externos. Caso haja esta necessidade deverá ser adquirida uma licença do tipo “Extended” exclusiva para o projeto.

Importante salientar que da mesma forma que o Spark foi integrado ao .NET no boilerplate, outros frameworks e temas de layout também poderão. Existem vários modelos disponíveis na web e comercializados por sites especializados.

Para utilizar o boilerplate blazorpost em uma aplicação siga os passos de criação de projeto e aplicação do Embrapa I/O e depois o passo a passo de configuração da solução.

Configurações e Padrões da solução

Estrutura da solution

A partir de 2026 o blazorpost deixou de ser um projeto único. A solution (Boilerplate4Dev.slnx) tem três projetos:

Boilerplate4Dev.csproj                          # host (Blazor Server): páginas, Identity,
                                                # admin transversal, ModuleRegistry
Core/Boilerplate4Dev.Core.csproj                # helpers e models institucionais, auditoria
                                                # centralizada, contratos e pontos de extensão
Integracoes/Boilerplate4Dev.Integracoes.csproj  # gateways institucionais (MongoDB corporativo,
                                                # foto de empregado)

O domínio de negócio de cada solução derivada vive em Razor Class Libraries próprias, em Modulos/<Modulo>/, e se pluga ao host por um único ponto de registro. A separação é garantida pelo compilador — um módulo simplesmente não consegue enxergar os tipos internos do host.

O detalhamento completo da arquitetura modular, com o guia para construção de módulos, está na seção Modularização.

Namespace raiz é Boilerplate4Dev, não blazorpost.

Convenções de layout

Conforme descrito anteriormente este boilerplate foi construído utilizando a biblioteca de componentes Bootstrap Blazor. Assim todas as classes e convenções de formatação, que não específicas do componente, devem seguir os recursos disponíveis nesta versão.

A biblioteca de ícones padrão do Blazor (Open-Iconic) também foi substituída pelas bibliotecas de ícones do Bootstrap Blazor (Bootstrap Icons e Font Awesome).

Convenções de código

Este boilerplate utiliza a convenção de código da Microsoft para o C#. Para dúvidas e consulta à forma de aplicação consulte a documentação oficial. Para auxiliar a aplicação destas convenções este projeto está utilizando o editorconfig padrão do dotnet.

Documentação das Variáveis de Ambiente

O appsettings.json usa placeholders substituídos pelos scripts scripts/generate-appsettings.sh / .ps1 a partir do ambiente (.env). Nunca faça hardcode de URLs ou segredos.

Configurações de Aplicação

ASPNET_ENV: Define o ambiente da aplicação (Development/Staging/Staging_2/Production)
BASE_URL: URL base da aplicação Blazor (local ex.: http://localhost:5205; no servidor, apontar para a URL da solução, ex.: https://boilerplate4dev-d.nuvem.ti.embrapa.br)
BLAZOR_PORT: Porta da aplicação Blazor (padrão: 5205)
BLAZOR_TRAEFIK_HOST: Nome do host Traefik para aplicações publicadas em clusters gerenciados pela solução Traefik (local: blazorpost.localhost; no servidor, enviar o domínio da URL a ser respondida pelo Traefik)
LOG_LEVEL: Nível de log da aplicação (Ex.: Debug)
IO_PROJECT: Nome do projeto
IO_APP: Nome da aplicação
IO_STAGE: Estágio do ambiente (development/alpha/beta/release)
IO_VERSION: Versão da aplicação
IO_DEPLOYER / IO_SERVER: Responsável e servidor do deploy (preenchidos pelo Embrapa I/O)

Configuração do Banco de Dados (PostgreSQL)

DB_HOST: Endereço e porta do PostgreSQL (padrão: postgres:5432)
DB_NAME: Nome do banco de dados (padrão: blazorserverapp)
DB_PASS: Senha do banco de dados
DB_USER: Usuário do banco de dados (padrão: blazorserverapp_user)
DB_VOLUME_NAME: Nome do volume Docker para persistência do PostgreSQL

Configuração do pgAdmin

PGADMIN_ROOT_USER: E-mail do administrador do pgAdmin
PGADMIN_PASSWORD: Senha do administrador do pgAdmin
PGADMIN_PORT: Porta da interface web do pgAdmin (padrão: 5050)
PGADMIN_TRAEFIK_HOST: Host Traefik para o pgAdmin (local: pgadmin.localhost)
PGADMIN_VOLUME_NAME: Nome do volume Docker para dados do pgAdmin

Autenticação — Keycloak (OIDC)

KEYCLOAK_AUTHORITY: URL do realm do Keycloak (ex.: https://KEYCLOAK_HOST/realms/REALM_NAME)
KEYCLOAK_CLIENT_ID: Identificador do client OIDC da aplicação
KEYCLOAK_CLIENT_SECRET: Segredo do client OIDC da aplicação

Atenção: estas três variáveis são obrigatórias — a aplicação falha no startup se algum placeholder não for substituído. A URI de redirecionamento cadastrada no client deve terminar em /signin-oidc.

Autenticação — administração de realm e cadastro externo

KEYCLOAK_ADMIN_CLIENT_ID / KEYCLOAK_ADMIN_CLIENT_SECRET: credenciais de administração do realm, exigidas somente quando o autocadastro de usuários externos estiver habilitado
KEYCLOAK_CADASTRO_EXTERNO_HABILITADO: liga/desliga o autocadastro de usuários externos
KEYCLOAK_FEDERACAO_EXTERNA_NOME: nome da federação externa configurada no realm
KEYCLOAK_FORCAR_LOGIN_INTERATIVO: força a tela de login a cada autenticação
KEYCLOAK_REVINCULACAO_MIGRACAO_HABILITADA: habilita a revinculação de contas migradas do antigo login Google

Sessão

SESSAO_EXPIRACAO_MINUTOS: tempo total da sessão do usuário (padrão: 120)
SESSAO_AVISO_MODAL_MINUTOS: antecedência, em minutos, do modal de aviso de expiração (padrão: 2)

Dados corporativos (MongoDB do ETL — apenas na Sede)

MONGO_CONNECTION_STRING: string de conexão do MongoDB corporativo
MONGO_DATABASE_NAME: nome do banco (ex.: etl_data)
MONGO_HOST_IP: IP mapeado para os hosts mongo1..3 dentro do container (extra_hosts)

Portal Embrapa (foto do empregado)

EMBRAPA_PORTAL_API_URL: URL base da API do Portal (padrão: https://www.embrapa.br/api/jsonws/)
EMBRAPA_PORTAL_COMPANY_ID: identificador da companhia no Portal (padrão: 10154)
EMBRAPA_PORTAL_API_USERNAME / EMBRAPA_PORTAL_API_PASSWORD: credenciais de acesso, solicitadas à equipe da SDSS

Configuração JWT

JWTBEARERTOKEN_AUDIENCE: Público-alvo do token JWT (padrão: Audience)
JWTBEARERTOKEN_EXPIRETIME: Tempo de expiração do token JWT em minutos
JWTBEARERTOKEN_ISSUER: Emissor do token JWT (padrão: https://www.embrapa.br/)
JWTBEARERTOKEN_SECRETKEY: Token JWT gerado a partir do Payload e Secret informados

Estes tokens são emitidos pela própria aplicação (para APIs que ela venha a expor) e são independentes dos tokens do Keycloak. Para gerar o token você pode usar um site como o jwt.io, escolher a opção de encoder e informar os seguintes parâmetros:

HEADER:

    {
        "alg": "HS256",
        "typ": "JWT"
    }

PAYLOAD:

    {
        "audience": "Audience",
        "issuer": "https://embrapa.br",
        "iat": 1749474900000,
        "exp": 1749478500000
    }

Os valores audience e issuer devem estar em conformidade com o informado nas variáveis JWTBEARERTOKEN_AUDIENCE e JWTBEARERTOKEN_ISSUER, respectivamente.

SECRET: informe uma chave alfanumérica de pelo menos 256 bits. Ex.: chave-gerada-boilerplate-dotnet-embrapa-io

Análise e Monitoramento

MATOMO_APIURL: URL da API do Matomo (padrão: https://hit.embrapa.io/)
MATOMO_ID: ID de rastreamento do Matomo. Valor injetado pelo Embrapa I/O ou disponível na dashboard da solução
MATOMO_TOKEN: token de acesso à API do Matomo, quando a solução consulta métricas
SENTRY_DSN: URL para monitoramento de erros no Sentry. Disponível na dashboard do Embrapa I/O

Outras Configurações

BASE_ROUTE_INTEGRACAO_API: Rota base para integração de APIs, caso a solução exponha APIs para consultas externas

Estas variáveis são utilizadas nos arquivos docker-compose.yaml e docker/Dockerfile para configurar o container da aplicação Blazor, o container do PostgreSQL, a interface do pgAdmin, o roteamento Traefik, os mecanismos de autenticação, as integrações e o monitoramento.

Migrando de uma versão anterior do boilerplate? As variáveis GOOGLE_CLIENTID, GOOGLE_CLIENTSECRET, API_GATEWAY_URL, API_GATEWAY_USERNAME, API_GATEWAY_PASSWORD, EMPREGADO_API_BASE_PATH e UNIDADE_API_BASE_PATH não existem mais. Foram substituídas, respectivamente, pelas variáveis KEYCLOAK_* e MONGO_*.

Consumindo uma API corporativa via API Gateway

Como o consumo de dados corporativos passou a ser feito por conexão direta ao MongoDB do ETL, o registro do HttpClient autenticado no API Gateway corporativo foi removido do boilerplate.

Você vai precisar registrá-lo novamente em dois casos: se a sua solução for hospedada fora da rede da Sede (onde o MongoDB corporativo não é acessível e os dados corporativos têm de vir 100% das APIs — ver o item 8 do FAQ), ou se ela precisar consumir alguma outra API corporativa. O procedimento é o mesmo:

Obtenha as credenciais de acesso junto à equipe responsável, pelo portal de APIs;
Adicione os placeholders no appsettings.json (ex.: API_GATEWAY_URL, API_GATEWAY_USERNAME, API_GATEWAY_PASSWORD) e as substituições correspondentes em scripts/generate-appsettings.sh / .ps1;
Declare as variáveis no .env.example, no docker-compose.yaml (seção environment do serviço da aplicação) e no .embrapa/settings.json;

Registre o HttpClient nomeado no Program.cs (autenticação Basic):

 builder.Services.AddHttpClient("GatewayAPI", httpClient =>
 {
     httpClient.BaseAddress = new Uri(builder.Configuration["BaseUrl:APIGatewayUrl"]);
     var basicAuthenticationValue = Convert.ToBase64String(Encoding.ASCII.GetBytes(
         $"{builder.Configuration["Authentication:ApiGateway:Username"]}:{builder.Configuration["Authentication:ApiGateway:Password"]}"));
     httpClient.DefaultRequestHeaders.Authorization =
         new AuthenticationHeaderValue("Basic", basicAuthenticationValue);
     // Teto explícito: sem Timeout, o default de 100s segura a requisição quando a API pendura.
     httpClient.Timeout = TimeSpan.FromSeconds(15);
 });

Consuma via IHttpClientFactory em um Service (não em um Controller):

 var client = _httpClientFactory.CreateClient("GatewayAPI");
 var resposta = await client.GetFromJsonAsync<MeuDto>("empregadoapi-h/v1/empregados/123");

Atenção: o caminho base das APIs corporativas muda conforme o ambiente (ex.: empregadoapi-d/, empregadoapi-h/, empregadoapi-p/). Estes valores devem ser alterados conforme o estágio de publicação da solução.

Tratamento de Exceção

Os erros podem ser detectados em quatro escopos diferentes:

1 - Erro de primeira solicitação: este escopo detecta erros quando o Blazor falha ao iniciar. É tratado pela seguinte linha no Program.cs:

    app.UseExceptionHandler("/Error");

2 - Global: se o Blazor for iniciado com êxito, este é o último recurso para lidar com quaisquer erros. É tratado pelo bloco blazor-error-ui, hoje declarado em Components/Shared/MainLayout.razor:

      <div id="blazor-error-ui">
          Ocorreu um erro. Este aplicativo pode não responder mais até ser recarregado.
          <a href="" class="reload">Recarregar</a>
          <a class="dismiss">🗙</a>
      </div>

3 - Layout: este escopo captura qualquer erro gerado no layout, desde que o Blazor tenha iniciado com sucesso. É tratado pelo <ErrorBoundary> em Components/Shared/MainLayout.razor.

4 - Componente: este escopo captura qualquer erro gerado dentro do componente, desde que o Blazor tenha iniciado com êxito. O tratamento é feito por blocos try/catch.

Para as integrações institucionais (MongoDB corporativo, foto do empregado), uma falha de comunicação lança IntegracaoIndisponivelException, que deve ser tratada pelo chamador para degradar a tela de forma controlada.

Nota para quem vem de versões anteriores: o arquivo _Host.cshtml e o ExceptionHandlingMiddleware global para HttpClient não existem mais no boilerplate.

Implementando autorização no projeto

A autorização é baseada em permissões: o código da aplicação não conhece perfis — conhece apenas permissões (ações granulares e estáveis, como Auditoria.Consultar). O vínculo entre perfil e permissões fica no banco (tabela AspNetRoleClaims do Identity) e é gerenciado em tempo de execução pela tela Gestão de Usuário → Permissões (/admin/usermanagement/permissoes).

Criar um perfil novo ou mudar o que um perfil pode fazer é operação de dados, não de código.

Componentes

Arquivo	Papel
`Data/Security/Permissoes.cs`	Catálogo de permissões da plataforma (única parte que vive no código), agrupado em classes aninhadas; lido por reflexão pela tela admin e pelo seed
`Data/Security/PermissaoRequirement.cs`	Requirement de autorização com o nome da permissão
`Data/Security/PermissaoHandler.cs`	Autoriza quando o principal possui o claim `permissao` com o valor exigido
`Data/Security/PermissaoPolicyProvider.cs`	Policy provider dinâmico: qualquer policy desconhecida vira exigência de permissão — não é preciso registrar uma policy por permissão no `Program.cs`
`Data/Services/PermissaoService.cs`	Lê e sincroniza os claims de permissão dos perfis e atualiza o security stamp dos usuários afetados
`Components/Pages/Admin/PermissoesPerfil.razor`	Tela admin: seleciona-se o perfil e as permissões são ligadas/desligadas com switches (o Administrador não aparece — sempre tem tudo)

Como proteger uma nova funcionalidade

Declare a permissão no catálogo (Data/Security/Permissoes.cs), em um grupo novo ou existente:

 public static class Clientes
 {
     public const string Visualizar = "Clientes.Visualizar";
     public const string Editar = "Clientes.Editar";
 }

Use a permissão como policy — em uma página:

 @attribute [Authorize(Policy = Permissoes.Clientes.Visualizar)]

Em um trecho de UI:

 <AuthorizeView Policy="@Permissoes.Clientes.Editar">
     <Button Type="ButtonType.Submit" Color="ButtonColor.Primary"> Salvar </Button>
 </AuthorizeView>

Em uma API/Controller:

 [Authorize(Policy = Permissoes.Clientes.Visualizar)]
 [HttpGet]
 public async Task<PaginatedList<Cliente>> GetClientes(...)

Conceda a permissão aos perfis desejados pela tela de Permissões. Não é necessário nenhum registro adicional no Program.cs.

Nunca use string literal de papel ou permissão fora do catálogo. Se a sua solução for modularizada, cada módulo mantém o seu próprio catálogo de papéis e permissões, com prefixo — veja a seção Modularização.

Banco de dados: sem EF Migrations

A aplicação nunca executa DDL. Não há EF Migrations no boilerplate: o schema é versionado em scripts/postgres/*.sql e executado na criação do container do banco, com a ordem fixada em docker/Dockerfile.postgres. Para desenvolvimento local, scripts/start-db.sh (ou .ps1) sobe o PostgreSQL já com o schema aplicado.

O acesso a dados é sempre por IDbContextFactory + await using, nunca injetando o DbContext diretamente — recomendação padrão para Blazor Server.

Configuração da solução para acesso à arquivos externos (Opcional)

Para que uma solução baseada no boilerplate possa ter acesso à arquivos externos (Ex.: Funcionalidade de upload e download de arquivos) é necessário realizar algumas configurações tanto no host docker, quanto no projeto da solução, conforme detalhadas a seguir.

Host Docker

Crie a pasta no nfs do host docker que irá hospedar a solução;

Altere a permissão da pasta para o grupo docker, conforme exemplo abaixo:

 #!/bin/bash
 #Directory creation
 mkdir /nfs/plat_xxx/solucaoyyy

 #Docker group permission
 chgrp -R docker /nfs/plat_xxx/solucaoyyy
 chmod -R g=rwx /nfs/plat_xxx/solucaoyyy

Crie o volume docker apontando para a nova pasta criada, conforme exemplo abaixo:
```
 docker volume create \
 --driver local \
 -o o=bind \
 -o type=none \
 -o device=/nfs/plat_xxx/solucaoyyy \
 embrapadevops_solucaoyyy_volume
```
Atenção o Embrapa I/O possui um padrão de criação de volumes que deve ser respeitado na hora da configuração para publicação de uma solução nos clusters. Para maiores informações consulte aqui a documentação, mais especificamente Passo 3: Volumes e Passo 4: Environment Variables.

Solução

Altere o Dockerfile da solução para criar um diretório que poderá ser mapeado para um volume externo.

 FROM base AS final
 WORKDIR /app
 RUN mkdir -p /data/external
 VOLUME /data/external
 ENV ASPNETCORE_HTTP_PORTS=80
 ENV ASPNETCORE_ENVIRONMENT=ASPNET_ENV
 ENV ASPNETCORE_FORWARDEDHEADERS_ENABLED=true
 ENV TZ=America/Sao_Paulo

Altere o arquivo docker-compose.yaml para utilizar o novo volume na hora da execução da solução:

 blazorpost:
     depends_on:
     - postgres
     build:
     context: .
     dockerfile: ./docker/Dockerfile
     args:
     ....
     volumes:
       - blazorpost_data:/data/external
     ....
 volumes:
   blazorpost_data:
     name: ${BLAZORPOST_VOLUME_NAME}
     external: true

Configure o projeto para utilizar o novo diretório para armazenamento dos arquivos. Como a solução irá enxergar somente o contexto do container docker, a pasta será sempre a mesma em todos os ambientes, ou seja “/data/external”, assim sugerimos deixar esta configuração fixa no arquivo appsettings.json, por exemplo:
```
     "UploadFolder": "/data/external",
```

Gestão de pacotes da solução

Importante: o boilerplate usa Central Package Management (CPM). As versões de todos os pacotes vivem exclusivamente no arquivo Directory.Packages.props, na raiz da solution, em elementos PackageVersion. Nenhum .csproj declara Version — declarar falha o restore. Ao adicionar um pacote novo: a versão entra no Directory.Packages.props e o PackageReference vai sem Version no csproj.

Renovate

Os boilerplates já vêm com o arquivo renovate.json configurado, que abre automaticamente merge requests de atualização de dependências no repositório do Gitlab. Esta é a forma recomendada de manter os pacotes em dia.

C# Dev Kit

Para quem utiliza a IDE VSCode, com o Plugin C# Dev Kit instalado você tem acesso a um gestor de pacotes NuGet. Basta executar Ctrl+Shift+P para abrir a paleta de comandos e localizar as opções “Nuget: …”.

Gestão de Pacotes pelo C# Dev Kit

Nesta modalidade todas as ações de adição, remoção e atualização são feitas individualmente, pacote a pacote.

dotnet-outdated

Outra opção é a ferramenta dotnet-outdated, que permite analisar e atualizar todos os pacotes em uso de uma única vez. Para instalar:

dotnet tool install --global dotnet-outdated-tool

Para analisar um projeto, execute na pasta onde o arquivo .csproj está localizado:

dotnet outdated

Ele irá exibir um relatório de todos os pacotes que possuem atualização na solução.

Relatório de análise de atualização de pacotes

Após avaliação, caso queira atualizar os pacotes indicados no relatório, execute:

dotnet outdated --upgrade

Um novo relatório será exibido indicando se os pacotes puderam ser atualizados com sucesso.

Relatório de atualização de pacotes

Atenção: sob CPM, confira sempre se a atualização foi gravada no Directory.Packages.props, e não como um atributo Version dentro de algum .csproj.

Executar outdated ao abrir a solução

Crie ou edite o arquivo tasks.json no diretório .vscode da sua solução, adicionando a seguinte configuração:

 {
     "version": "2.0.0",
     "tasks": [
         {
         "label": "dotnet-outdated",
         "type": "shell",
         "command": "dotnet outdated",
         "group": "build",
         "problemMatcher": [],
         "runOptions": {
             "runOn": "folderOpen"
         }
         }
     ]
 }

Salve as alterações e abra a solução no VSCode. O comando dotnet outdated deve ser executado automaticamente.

Referências utilizadas na confecção deste boilerplate

dotnetapi

Este projeto é um boilerplate para desenvolvimento de APIs REST utilizando a plataforma .NET 10 e ASP.NET Core. Inclui integração com Matomo para análise de tráfego, Sentry para monitoramento de erros, e está configurado para deployment com Docker e Docker Compose.

Configurações e Padrões da solução

Convenções de código

Funcionalidades

API REST com minimal endpoints
Health checks integrados
Monitoramento com Matomo Analytics
Rastreamento de erros com Sentry
Endpoints para publicação e consulta de relatórios de teste
Suporte a Docker e Docker Compose
Configuração para ambientes de desenvolvimento, staging e produção
Documentação OpenAPI

Pré-requisitos

.NET 10 SDK
Docker 20.10+ (opcional, para containerização)
Docker Compose v2.0+ (opcional, para orquestração)

Instalação

Clone o repositório;

Crie uma cópia do arquivo .env.example como .env e gere o arquivo de configuração:

 ./scripts/generate-appsettings.sh    # Linux / Dev Container
 .\scripts\generate-appsettings.ps1   # Windows

Restaure as dependências:
```
 dotnet restore
```

Uso

Executando localmente

Para executar a aplicação em modo de desenvolvimento:

dotnet run

A API estará disponível em:

HTTP: http://localhost:5191
HTTPS: https://localhost:7284

Executando com Docker

Copie os arquivos de configuração de ambiente:

 cp .env.example .env
 cp .env.io.example .env.io

Configure as variáveis de ambiente nos arquivos .env e .env.io conforme necessário.

Construa e execute o container:

 env $(cat .env.io) docker compose up --force-recreate --build --remove-orphans --wait

A API estará disponível na porta configurada na variável API_PORT (padrão: 5191).

Endpoints disponíveis

GET /weatherforecast — Retorna previsão do tempo de exemplo
GET /healthcheck — Verifica o status da aplicação
GET /openapi — Documentação OpenAPI (apenas em desenvolvimento)
POST /tests/test-report/upload — Publica um relatório de teste
GET /tests/test-report/ — Relatório de teste em HTML
GET /tests/test-report/json — Relatório de teste em JSON
GET /tests/test-report/summary — Resumo do relatório de teste

Configuração

Variáveis de ambiente

Principais variáveis configuráveis no arquivo .env:

API_PORT: Porta da API (padrão: 5191)
API_MANAGER_IP: IP do API Manager corporativo, quando a API é publicada atrás dele
ASPNET_ENV: Ambiente da aplicação (Development/Staging/Production)
LOG_LEVEL: Nível de log (Debug/Information/Warning/Error)
PATH_BASE: Caminho base da API (padrão: /api/v1)
TRAEFIK_HOST: Host Traefik para publicação em clusters gerenciados
MATOMO_APIURL: URL da API do Matomo para analytics
SENTRY_DSN: DSN do Sentry para monitoramento de erros

Monitoramento

O projeto inclui integração com:

Matomo: para análise de tráfego e comportamento dos usuários
Sentry: para rastreamento e monitoramento de erros em tempo real

Estrutura do projeto

dotnetapi/
├── Program.cs               # Ponto de entrada da aplicação
├── DotNetApi.csproj         # Arquivo de projeto .NET
├── DotNetApi.slnx           # Solution (formato .slnx do .NET 10)
├── appsettings.json         # Configurações da aplicação (placeholders)
├── docker-compose.yaml      # Configuração Docker Compose
├── Docker/                  # Dockerfile para containerização
├── EndPoints/               # Definição dos minimal endpoints
├── Reports/                 # Relatórios de teste publicados
├── TestFiles/               # Arquivo endpoints.http para testes manuais
├── Docs/                    # Documentação complementar do projeto
├── Properties/              # launchSettings.json
├── scripts/                 # Geração do appsettings a partir do .env
└── .env                     # Variáveis de ambiente

Testando a API

Você pode testar os endpoints usando o arquivo TestFiles/endpoints.http com extensões como REST Client no VS Code.