DEV Community: Danilo O. Pinheiro, dopme.io

🚀 Como comunicar .NET 10 com Pydantic usando Logfire

Danilo O. Pinheiro, dopme.io — Thu, 20 Aug 2026 13:47:37 +0000

Uma implementação simples de observabilidade com OpenTelemetry

Quando pensamos no ecossistema Pydantic, normalmente associamos a tecnologia ao Python, validação de dados e aplicações de Inteligência Artificial. Porém, existe uma possibilidade muito interessante para aplicações .NET: utilizar o Pydantic Logfire como plataforma de observabilidade para uma aplicação construída em .NET 10.

E aqui está o ponto mais importante:

Não precisamos criar uma integração específica entre .NET e Pydantic.

O caminho mais simples é utilizar o OpenTelemetry, padrão aberto utilizado pelo Logfire. O .NET envia traces, métricas e logs através do protocolo OTLP, e o Logfire recebe e apresenta essas informações em sua plataforma. (logfire.pydantic.dev)

Neste artigo, vamos construir uma implementação simples utilizando .NET 10 + ASP.NET Core + OpenTelemetry + Logfire.

🧭 O que vamos construir?

A arquitetura será propositalmente simples:

┌──────────────────────┐
│      Cliente         │
└──────────┬───────────┘
           │ HTTP
           ▼
┌──────────────────────┐
│      .NET 10 API     │
│                      │
│ ASP.NET Core         │
│ ILogger              │
│ Activity             │
│ Metrics              │
└──────────┬───────────┘
           │
           │ OTLP / HTTP
           ▼
┌──────────────────────┐
│   Pydantic Logfire   │
│                      │
│ Logs                 │
│ Traces               │
│ Metrics              │
└──────────────────────┘

O objetivo não é transformar o .NET em uma aplicação Python/Pydantic.

O objetivo é comunicar uma aplicação .NET com o ecossistema Pydantic através de um padrão de observabilidade aberto.

🧠 1. Onde entra o Pydantic?

O ecossistema Pydantic possui diferentes ferramentas.

Na imagem apresentada, podemos observar uma organização bastante interessante:

🏗️ Build

Pydantic AI
Pydantic Validation

🔄 Iterate

Pydantic Evals
Logfire Agent Optimization

🚀 Deploy & Monitor

Logfire Agent Monitoring
Logfire Infrastructure Monitoring
Logfire
Logfire AI Gateway

Para uma primeira implementação com .NET, entretanto, não precisamos começar por Pydantic AI, Evals ou AI Gateway.

A opção mais simples é:

.NET 10 → OpenTelemetry → Logfire

Isso reduz drasticamente a complexidade inicial.

O próprio Logfire informa que aplicações em linguagens compatíveis com OpenTelemetry podem enviar telemetria diretamente para sua infraestrutura. (logfire.pydantic.dev)

🔌 2. O que significa "comunicar .NET com Pydantic"?

É importante fazer uma distinção.

Não teremos necessariamente:

.NET
  ↓
Pydantic API

A arquitetura será:

.NET
  ↓
OpenTelemetry
  ↓
OTLP
  ↓
Logfire

O OTLP (OpenTelemetry Protocol) é justamente o protocolo utilizado para transportar dados de telemetria entre aplicações e backends compatíveis. (Microsoft Learn)

Isso também significa que a mesma aplicação poderia posteriormente enviar sua telemetria para outras plataformas compatíveis com OpenTelemetry.

🛠️ 3. Criando a API .NET 10

Vamos começar com uma aplicação mínima.

dotnet new webapi -n DotNetLogfire
cd DotNetLogfire

Confira o projeto:

dotnet run

Agora temos nossa API .NET 10.

📦 4. Instalando OpenTelemetry

Vamos instalar o exporter OTLP:

dotnet add package OpenTelemetry.Exporter.OpenTelemetryProtocol

Também podemos adicionar as instrumentações necessárias:

dotnet add package OpenTelemetry.Extensions.Hosting
dotnet add package OpenTelemetry.Instrumentation.AspNetCore
dotnet add package OpenTelemetry.Instrumentation.Http

O pacote OpenTelemetry.Exporter.OpenTelemetryProtocol fornece o exporter OTLP para aplicações .NET e é compatível com net10.0. (NuGet)

🔐 5. Criando um token no Logfire

No Logfire, crie um projeto e gere um write token.

Esse token será utilizado pela aplicação para autenticar o envio da telemetria.

Não coloque o token diretamente no código:

// ❌ Não faça isso
var token = "meu-token-real";

Prefira variável de ambiente:

LOGFIRE_TOKEN

Isso permite manter credenciais fora do código-fonte.

A documentação do Logfire utiliza o header de autorização para autenticar os dados enviados através de OTLP. (logfire.pydantic.dev)

🌐 6. Configurando o endpoint do Logfire

Para uma configuração simples, podemos utilizar:

OTEL_EXPORTER_OTLP_ENDPOINT=https://logfire-us.pydantic.dev

OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf

Além disso:

OTEL_EXPORTER_OTLP_HEADERS=Authorization=SEU_TOKEN

O Logfire documenta explicitamente essa configuração para clientes OpenTelemetry que não possuem um SDK específico do Logfire. (logfire.pydantic.dev)

Se seu projeto estiver utilizando a região europeia, utilize o endpoint correspondente do Logfire EU.

⚙️ 7. Configurando o OpenTelemetry no .NET

Agora vamos configurar o Program.cs.

using OpenTelemetry.Logs;
using OpenTelemetry.Metrics;
using OpenTelemetry.Trace;

var builder = WebApplication.CreateBuilder(args);

builder.Logging.AddOpenTelemetry(logging =>
{
    logging.IncludeFormattedMessage = true;
    logging.IncludeScopes = true;
});

builder.Services
    .AddOpenTelemetry()
    .WithTracing(tracing =>
    {
        tracing
            .AddAspNetCoreInstrumentation()
            .AddHttpClientInstrumentation();
    })
    .WithMetrics(metrics =>
    {
        metrics
            .AddAspNetCoreInstrumentation()
            .AddRuntimeInstrumentation();
    })
    .UseOtlpExporter();

var app = builder.Build();

app.MapGet("/", () =>
{
    return Results.Ok(new
    {
        message = "Hello Logfire!",
        timestamp = DateTime.UtcNow
    });
});

app.Run();

A estrutura segue o modelo recomendado pelo OpenTelemetry no .NET: ILogger para logs, ActivitySource para tracing e Meter para métricas. (Microsoft Learn)

📊 8. O que estamos enviando?

Agora temos três categorias principais.

📝 Logs

Gerados através de:

ILogger

Por exemplo:

app.MapGet("/products", (
    ILogger<Program> logger) =>
{
    logger.LogInformation(
        "Consultando produtos");

    return Results.Ok(new[]
    {
        "Notebook",
        "Mouse",
        "Keyboard"
    });
});

🔎 9. Traces

O OpenTelemetry consegue instrumentar automaticamente requisições HTTP do ASP.NET Core.

Por exemplo:

GET /products
      │
      ▼
ASP.NET Core
      │
      ▼
Controller / Endpoint
      │
      ▼
HttpClient
      │
      ▼
External API

Esse fluxo pode ser representado como um trace.

A grande vantagem é conseguir entender onde uma requisição gastou tempo.

📈 10. Métricas

Também podemos trabalhar com métricas.

Por exemplo:

HTTP Requests
Request Duration
Active Requests
Runtime Metrics
GC
CPU
Memory

O ASP.NET Core e o .NET já possuem diversas métricas instrumentadas, e o OpenTelemetry pode coletá-las. (Microsoft Learn)

🧪 11. Criando um endpoint para teste

Vamos criar um endpoint um pouco mais interessante:

app.MapGet("/orders/{id}", (
    int id,
    ILogger<Program> logger) =>
{
    logger.LogInformation(
        "Consultando pedido {OrderId}",
        id);

    if (id <= 0)
    {
        logger.LogWarning(
            "Pedido inválido: {OrderId}",
            id);

        return Results.BadRequest();
    }

    return Results.Ok(new
    {
        Id = id,
        Status = "Processed"
    });
});

Agora podemos testar:

GET /orders/10

GET /orders/0

Teremos dois comportamentos diferentes.

🔥 12. Gerando um erro proposital

Para entender melhor a observabilidade, podemos criar:

app.MapGet("/error", () =>
{
    throw new InvalidOperationException(
        "Erro de demonstração");
});

Quando acessarmos:

GET /error

teremos uma exceção.

O objetivo aqui é observar como o problema aparece no Logfire.

🔗 13. O fluxo completo

Agora nossa arquitetura está assim:

                    ┌───────────────────┐
                    │     Browser       │
                    │    Postman        │
                    │      Client       │
                    └─────────┬─────────┘
                              │
                              ▼
                    ┌───────────────────┐
                    │     .NET 10       │
                    │    ASP.NET Core   │
                    └─────────┬─────────┘
                              │
             ┌────────────────┼────────────────┐
             │                │                │
             ▼                ▼                ▼
          ILogger          Activity           Meter
             │                │                │
             └────────────────┼────────────────┘
                              ▼
                      ┌───────────────┐
                      │ OpenTelemetry │
                      └───────┬───────┘
                              │
                             OTLP
                              │
                              ▼
                     ┌─────────────────┐
                     │    Logfire      │
                     │   Pydantic      │
                     └─────────────────┘

Essa é a parte mais interessante da implementação.

Não criamos um SDK proprietário para integrar o .NET.

Utilizamos um padrão aberto.

🧩 14. Por que essa abordagem é interessante?

Imagine que amanhã você queira trocar o Logfire.

A aplicação não precisa ser completamente reescrita.

Poderíamos direcionar o OpenTelemetry para:

.NET
 │
 └── OpenTelemetry
       │
       ├── Logfire
       ├── Grafana
       ├── Datadog
       ├── Azure Monitor
       ├── New Relic
       └── Outro backend OTLP

Essa independência é justamente uma das principais vantagens do OpenTelemetry. (Microsoft Learn)

🏗️ 15. E onde entra o Pydantic AI?

Aqui começa uma arquitetura ainda mais interessante.

Podemos ter:

             ┌─────────────────┐
             │     .NET 10     │
             │       API       │
             └────────┬────────┘
                      │
                      │ HTTP
                      ▼
             ┌─────────────────┐
             │  Pydantic AI   │
             │     Agent      │
             └────────┬────────┘
                      │
                      ▼
                   LLM
                      │
                      ▼
                 Logfire

Nesse cenário, o .NET poderia ser responsável por:

APIs
autenticação
regras de negócio
banco de dados
integrações corporativas

Enquanto o ecossistema Pydantic poderia assumir:

agentes
validação
avaliação
workflows de IA

E o Logfire poderia fornecer uma camada de observabilidade.

🤖 16. Uma arquitetura híbrida .NET + Pydantic

Uma arquitetura mais completa poderia ficar assim:

                  Client
                     │
                     ▼
              ┌──────────────┐
              │   .NET 10    │
              │     API      │
              └──────┬───────┘
                     │
          ┌──────────┴──────────┐
          │                     │
          ▼                     ▼
     Business Rules         Pydantic AI
          │                     │
          │                     ▼
          │                    LLM
          │                     │
          └──────────┬──────────┘
                     ▼
                OpenTelemetry
                     │
                     ▼
                  Logfire

Isso cria uma separação interessante entre aplicação empresarial e camada de inteligência artificial.

🔐 17. Segurança

Um ponto extremamente importante é evitar enviar informações sensíveis para uma plataforma de observabilidade.

Por exemplo, evite:

logger.LogInformation(
    "Cartão: {CardNumber}",
    cardNumber);

Ou:

logger.LogInformation(
    "Token: {Token}",
    token);

Prefira:

logger.LogInformation(
    "Pagamento processado para o pedido {OrderId}",
    orderId);

O Logfire também possui mecanismos de processamento e redaction através do ecossistema OpenTelemetry Collector para cenários em que dados precisam ser filtrados antes do envio. (logfire.pydantic.dev)

🐳 18. E se eu quiser usar Docker?

A aplicação pode continuar sendo executada normalmente:

docker build -t dotnet-logfire .

docker run \
-e OTEL_EXPORTER_OTLP_ENDPOINT=https://logfire-us.pydantic.dev \
-e OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf \
-e OTEL_EXPORTER_OTLP_HEADERS="Authorization=SEU_TOKEN" \
-p 8080:8080 \
dotnet-logfire

Assim, as configurações permanecem fora da imagem.

📦 19. E o OpenTelemetry Collector?

Em uma arquitetura maior, podemos adicionar um Collector:

.NET 10
   │
   ▼
OpenTelemetry
   │
   ▼
OTel Collector
   │
   ├──────────────► Logfire
   │
   ├──────────────► Grafana
   │
   └──────────────► Datadog

Isso é particularmente interessante quando existe necessidade de:

filtragem;
redaction;
transformação;
roteamento;
múltiplos backends.

O próprio Logfire documenta o uso do OpenTelemetry Collector como camada intermediária para processamento e encaminhamento da telemetria. (logfire.pydantic.dev)

🧠 20. O que aprendemos?

A implementação demonstrou algo importante:

Integrar .NET com Pydantic não significa necessariamente consumir uma API Python diretamente.

Podemos utilizar o ecossistema de padrões que conecta as duas tecnologias.

A arquitetura utilizada foi:

.NET 10
   ↓
OpenTelemetry
   ↓
OTLP
   ↓
Pydantic Logfire

E isso nos permite observar:

Logs
Traces
Metrics

em uma plataforma construída para observabilidade de aplicações e sistemas de IA. O Logfire atualmente se posiciona justamente como uma plataforma de observabilidade baseada em OpenTelemetry para aplicações, serviços e agentes de IA. (Pydantic)

🚀 21. Próximo passo: .NET + Pydantic AI

Depois dessa primeira comunicação, podemos evoluir a arquitetura.

Nível 1 — Observabilidade

.NET 10
   ↓
OpenTelemetry
   ↓
Logfire

Nível 2 — API + Agent

.NET 10
   ↓
Pydantic AI
   ↓
LLM
   ↓
Logfire

Nível 3 — Arquitetura completa

                 Client
                   │
                   ▼
                .NET 10
                   │
          ┌────────┴────────┐
          ▼                 ▼
      Database        Pydantic AI
                            │
                            ▼
                           LLM
                            │
                            ▼
                       OpenTelemetry
                            │
                            ▼
                         Logfire

Essa evolução abre espaço para aplicações híbridas envolvendo .NET, agentes de IA, LLMs, observabilidade e arquitetura distribuída.

✅ Conclusão

O mais interessante nessa integração é justamente sua simplicidade.

Para começar, não precisamos criar uma ponte complexa entre .NET e Python.

Podemos utilizar:

.NET 10 + OpenTelemetry + OTLP + Logfire.

Com poucas configurações, uma aplicação .NET consegue enviar logs, traces e métricas para o Logfire, aproveitando um padrão aberto e independente de fornecedor. (logfire.pydantic.dev)

E essa abordagem pode ser o primeiro passo para uma arquitetura muito maior, conectando APIs .NET, Pydantic AI, agentes, LLMs e observabilidade.

Talvez a melhor forma de começar com Pydantic no .NET não seja começar pelo Pydantic — mas pelo OpenTelemetry.

🤝 Conecte-se Comigo

Se você trabalha com .NET moderno e quer evoluir em temas como arquitetura, C#, Inteligência Artificial, observabilidade, DevOps ou interoperabilidade, vamos conversar:

🌐 shifters.dev
💼 LinkedIn
💻 Dev.to
✍️ Medium
✍️ Substack
📬 contato@dopme.io

🔗 Referências

Eu lhes dou este novo mandamento: amem uns aos outros. Assim como eu os amei, amem também uns aos outros.
João 13:34

🚀 JWT sem hash forte de senha é armadilha — Argon2 + .NET fecham o ciclo

Danilo O. Pinheiro, dopme.io — Mon, 01 Jun 2026 00:51:21 +0000

A stack de autenticação em .NET fica sólida quando separamos duas responsabilidades:

✅ Argon2id para guardar senhas (hash irreversível, lento, memória-intensivo)

✅ JWT Bearer para provar identidade depois do login

✅ Validação de iss, aud, exp e assinatura em cada request

✅ Segredos fora do repositório (ambiente / Key Vault)

Se o ecossistema .NET já oferece hosting, APIs e pacotes maduros, combinar Argon2 (referência da Password Hashing Competition, testável em argon2.online) com JWT é o caminho natural para microsserviços e Web APIs.

Neste artigo, mostro o fluxo registo → login → token → rotas protegidas com foco no que implementar no dia a dia.

⚠️ Observação importante

JWT não substitui Argon2. Nunca coloque senha ou hash no payload do token. Argon2 protege a credencial na base de dados; JWT é sessão assinada com expiração.

🧠 Visão Geral

Aspecto	Argon2 (senha)	JWT (sessão)
Foco	Resistir a offline cracking	Autorizar requests após login
Onde vive	Coluna `password_hash` na BD	Header `Authorization: Bearer`
Algoritmo	Argon2id (OWASP)	HMAC-SHA256 ou RSA (config)
Ferramenta de estudo	argon2.online	docs Microsoft JWT Bearer
Runtime	Biblioteca .NET (ex.: Konscious Argon2)	`Microsoft.AspNetCore.Authentication.JwtBearer`
Erro clássico	MD5/SHA rápido na senha	Token sem validar `aud`/`iss`

🧩 O que o Argon2 resolve (camada 1)

O Argon2 é o vencedor da Password Hashing Competition — hoje a referência para novas passwords.

1️⃣ Hash irreversível com Argon2id

var hash = hasher.Hash(password);
await store.CreateAsync(email, hash);

✅ Salt único por utilizador

✅ Parâmetros m, t, p documentados no próprio hash

✅ Verificação com tempo constante (FixedTimeEquals)

2️⃣ Calibrar custo com consciência

Em argon2.online podes experimentar memory cost e iterations — útil em laboratório.

📌 Em produção usa biblioteca auditada (.NET), não hashes de utilizadores reais em sites públicos.

3️⃣ O que não fazer na senha

✅ Não “criptografar” senha com AES reversível

✅ Não MD5 / SHA-1 / SHA-256 simples

✅ Não logar password nem hash em erros

🚀 O que o JWT resolve no .NET (camada 2)

Depois de Verify com sucesso, o .NET emite um token assinado.

1️⃣ Emissão após login

Sem JWT (só sessão server-side):

Cookie de sessão + estado no servidor

Com JWT Bearer (API stateless):

var jwt = tokens.CreateToken(user.Id, user.Email, user.Roles);
return Results.Ok(new { accessToken = jwt, tokenType = "Bearer" });

📌 Claims mínimos: sub, email, role — sem senha no token.

2️⃣ Validação no pipeline ASP.NET Core

options.TokenValidationParameters = new TokenValidationParameters
{
    ValidateIssuer = true,
    ValidateAudience = true,
    ValidateLifetime = true,
    ValidateIssuerSigningKey = true,
};

✅ Rejeita token expirado

✅ Rejeita iss/aud incorretos

✅ Protege rotas com .RequireAuthorization()

3️⃣ Segredo de assinatura

Jwt:SigningKey → variável de ambiente / Key Vault (NUNCA no Git)

📌 Rotação de chave planeada em produção.

4️⃣ Pacotes no ecossistema .NET

Microsoft.AspNetCore.Authentication.JwtBearer
System.IdentityModel.Tokens.Jwt
Konscious.Security.Cryptography.Argon2 (ou equivalente Argon2id)

➡️ Alinhado ao stack oficial em dotnet.microsoft.com

➡️ APIs, cloud e tooling no mesmo SDK

5️⃣ Hardening obrigatório

Rate limit em /auth/login
HTTPS em produção
Mensagem genérica em falha de login (não revelar se email existe)

📌 Ideal para APIs expostas na internet e microsserviços.

🏗️ Impacto Arquitetural

🔹 APIs ASP.NET Core

Login local com Argon2 + JWT para o resto da API
Gateway (YARP) pode reencaminhar o Bearer token

🔹 SPAs e Blazor WASM

Login via API — hash de senha no servidor, não só no browser
Preferir cookie HttpOnly ou memória volátil ao localStorage se XSS for risco

🔹 Equipas de segurança

ADR: Argon2id + validação JWT completa
argon2.online apenas para testes de parâmetros

📊 Comparação prática

Errado

new Claim("password", password) // NUNCA no JWT

Certo

// BD: Argon2
var hash = hasher.Hash(password);

// Login OK → JWT
var token = tokens.CreateToken(userId, email, roles);

🧩 Quando adotar JWT + Argon2?

✅ Adote se:

Expõe REST/Minimal API em .NET
Precisa de auth stateless entre serviços
Controla login local (email/senha)

⚠️ Avalie com cautela se:

Só login corporativo → OpenID Connect / Entra ID
Monólito com sessão simples → cookies + Identity pode bastar

🔮 Direção da autenticação .NET

Menos hashes fracos em legado
Mais Argon2id + políticas OWASP
JWT com validação estrita e refresh tokens rotativos
MFA além de senha forte
Integração cloud nativa no .NET

✅ Conclusão

JWT com Argon2 no .NET não é moda: é separação correta — argon2.online e a documentação Argon2 ajudam a entender o hash; dotnet.microsoft.com é a base para APIs e pacotes JWT.

O resultado é login defensável e APIs autorizadas sem confundir «token» com «senha guardada».

Artigo completo: https://dopme.io/centro-conhecimento/artigos/seguranca/jwt-argon2-dotnet

🤝 Conecte-se comigo

Se você trabalha com .NET moderno e quer evoluir em temas como arquitetura, C#, DevOps, segurança e interoperabilidade, vamos conversar:

💼 Linkedin
💻 Devto
✍️ Medium
📰 Substack

Não vos escrevi porque não soubésseis a verdade, mas porque a sabeis, e porque nenhuma mentira é da verdade. 1 João 2:21

🚀 C# 14 já estava bom… agora ficou ainda melhor

Danilo O. Pinheiro, dopme.io — Mon, 23 Mar 2026 01:31:39 +0000

🚀 C# 14 já estava bom… agora ficou ainda melhor

Comparando C# 14 vs C# 15 e o que muda na prática para desenvolvedores .NET

A evolução do C# segue um padrão cada vez mais claro:

✅ reduzir complexidade

✅ aumentar expressividade

✅ melhorar performance

✅ elevar a produtividade do desenvolvedor

Se o C# 14 já consolidou uma linguagem mais limpa, moderna e consistente, o C# 15 (ainda em evolução) dá mais um passo importante rumo a um ecossistema mais fluido, seguro e alinhado às demandas do desenvolvimento moderno em .NET.

Neste artigo, exploramos as principais diferenças entre C# 14 e C# 15, com foco no impacto real no dia a dia de quem desenvolve aplicações .NET.

⚠️ Observação importante

O C# 15 encontra-se em fase de preview/evolução. Os exemplos apresentados refletem direções e conceitos esperados, podendo sofrer ajustes até a versão final.

🧠 Visão Geral

Aspecto	C# 14	C# 15
Foco	Simplificação e consistência	Produtividade e redução de boilerplate
Sintaxe	Mais limpa	Ainda mais concisa
Pattern Matching	Avançado	Mais poderoso e flexível
Coleções	Simplificadas	Expandidas
Interoperabilidade	Melhorias incrementais	Mais abstração e segurança
Experiência do Dev	Boa	Ainda melhor

🧩 O que o C# 14 trouxe

O C# 14 consolidou melhorias importantes que vinham sendo introduzidas ao longo das versões anteriores.

1️⃣ Inicialização simplificada de coleções

List<int> numbers = [];

✅ Menos código

✅ Mais legibilidade

✅ Sintaxe mais direta

2️⃣ Pattern Matching mais expressivo

if (user is { Age: > 18, Active: true })
{
    Console.WriteLine("Usuário válido");
}

✅ Código mais declarativo

✅ Redução de if/else encadeados

✅ Melhor leitura da intenção

3️⃣ Melhor suporte a cenários de performance

Span<int> data = stackalloc int[10];

✅ Menos alocações no heap

✅ Melhor uso de memória

✅ Ideal para sistemas de alta performance

🚀 O que o C# 15 melhora

O C# 15 não é uma revolução, mas sim uma evolução refinada do que já vinha sendo construído.

1️⃣ Ainda menos boilerplate

A proposta é reduzir ainda mais código repetitivo.

C# 14:

var user = new User { Name = "Danilo", Age = 30 };

C# 15 (conceito esperado):

User user = { Name: "Danilo", Age: 30 };

📌 Inicialização mais direta, fluida e expressiva.

2️⃣ Pattern Matching ainda mais poderoso

Expansão dos padrões compostos:

if (order is { Items.Count: > 0 } and { Status: "Paid" })
{
    Console.WriteLine("Pedido válido");
}

✅ Menos código imperativo

✅ Mais clareza semântica

✅ Melhor leitura da regra de negócio

3️⃣ Evolução no suporte a coleções

Ampliação das collection expressions:

var values = [1, 2, 3, ..otherValues];

📌 Composição de dados mais simples e natural.

4️⃣ Funções e expressões mais diretas

int Sum(int a, int b) => a + b;

➡️ Mais coerência com estilos funcionais

➡️ Código mais enxuto e previsível

5️⃣ Interoperabilidade ainda mais forte

O C# 15 continua evoluindo cenários críticos como:

Span<T>
Memory<T>
Interop com código nativo
APIs de alto desempenho

📌 Ideal para sistemas críticos, de alta escala e baixa latência.

🏗️ Impacto Arquitetural

🔹 Aplicações corporativas

Código mais limpo
Menos repetição
Melhor manutenção e evolução

🔹 Sistemas distribuídos

Modelagem de dados mais clara
Menor acoplamento
APIs mais expressivas

🔹 Times de desenvolvimento

Padronização mais simples
Onboarding mais rápido
Revisões de código mais eficientes

📊 Comparação prática

C# 14

var users = new List<string> { "Ana", "Carlos" };

C# 15

var users = ["Ana", "Carlos"];

C# 14

if (user != null && user.IsActive)
{
    Console.WriteLine(user.Name);
}

C# 15

if (user is { IsActive: true } u)
{
    Console.WriteLine(u.Name);
}

🧩 Quando atualizar?

✅ Atualize para C# 15 se:

Já utiliza versões recentes do .NET
Busca reduzir boilerplate
Quer código mais expressivo
Está iniciando novos projetos

⚠️ Avalie com cautela se:

O projeto é legado e crítico
Ferramentas e bibliotecas ainda não suportam totalmente

🔮 Direção do C\

O caminho do C# está cada vez mais claro:

Menos código repetitivo
Mais expressividade
Mais segurança
Melhor performance
Integração cada vez maior com cloud e microserviços

✅ Conclusão

Se o C# 14 já entregou uma experiência moderna e produtiva, o C# 15 dá continuidade a essa evolução com foco em simplicidade, fluidez e consistência.

Não se trata de mudanças radicais, mas de refinamentos que fazem grande diferença no dia a dia, especialmente em projetos grandes e times distribuídos.

O resultado é uma linguagem cada vez mais preparada para os desafios do desenvolvimento moderno.

🤝 Conecte-se comigo

Se você trabalha com .NET moderno e quer evoluir em temas como arquitetura, C#, DevOps e interoperabilidade, vamos conversar:

💼 Linkedin
💻 Devto
✍️ Medium
📰 Substack

Não vos escrevi porque não soubésseis a verdade, mas porque a sabeis, e porque nenhuma mentira é da verdade. 1 João 2:21

Dez tecnologias essenciais em .NET

Danilo O. Pinheiro, dopme.io — Sat, 21 Mar 2026 20:35:53 +0000

Este material está alinhado à conversa em vídeo “10 coisas que você deve fazer na sua aplicação .NET”, publicada no YouTube pelo canal Eximiaco — Excelência Tecnológica.

Gabriel Kohlrausch conduz a conversa com Bruno Joaquim (desenvolvimento .NET/Node.js e Kafka) e Francisco Schneider (especialista em .NET em aplicações corporativas complexas). Página oficial da live e resumo do tema: EximiaCo — 10 coisas que você deve fazer na sua aplicação .NET. Perfil do mediador na consultoria: Gabriel Kohlrausch — EximiaCo.

O repositório dopTenEssentialTechNet não substitui a palestra: ele oferece laboratórios em console para experimentar, no código, temas que dialogam com essa linha de boas práticas em aplicações .NET.

Introdução

Dominar o ecossistema .NET moderno vai além da linguagem C#: envolve configuração, hospedagem, HTTP resiliente, dados, testes e observabilidade. O repositório dopTenEssentialTechNet reúne aplicativos de console independentes, todos com .NET 10 (net10.0), cada um focado em um tema recorrente em projetos reais — em sintonia com a conversa citada acima.

Este texto descreve o propósito do repositório, o que cada projeto representa e como utilizá-lo como material de estudo ou referência.

Objetivo do repositório

Centralizar exemplos mínimos executáveis (console), fáceis de abrir e rodar.
Separar um tema por pasta, sem misturar dependências desnecessárias entre exemplos.
Servir de base para artigos, treinamentos ou experimentos isolados.

A solução está em dopTenEssentialTechNet.sln na raiz; cada subpasta é um projeto .csproj próprio.

Projetos e temas

Projeto	O que se pretende explorar
SubStringSpan	Manipulação eficiente de texto com `Span<T>`, `ReadOnlySpan<char>` e `Memory<T>`, reduzindo alocações.
OptionsConfig	Padrão Options (`IOptions`, `IOptionsSnapshot`) e ligação com `IConfiguration`.
BackgroundServer	Hospedagem com `Host` / `IHostedService` e execução contínua em segundo plano.
WorkflowCore	Definição e execução de fluxos com a biblioteca WorkflowCore.
VerticalSliceFastEndpoints	Estrutura em fatias verticais usando FastEndpoints (API enxuta sobre ASP.NET Core).
HTTPolly	Chamadas HTTP com Polly (retentativas, circuit breaker, timeouts).
Flurl	Cliente HTTP declarativo com Flurl.Http.
TddContainers	Testes de integração com Testcontainers (dependências reais em containers).
DynamicDapper	Consultas e cenários dinâmicos com Dapper.
ContextPool	Uso de pooling de contexto (por exemplo, `DbContext` com pool de conexões).
SourceGeneratedLogging	Logging com source generators (APIs geradas em tempo de compilação).

Os códigos evoluem com o tempo; a tabela acima define a intenção pedagógica de cada pasta.

Pré-requisitos

SDK .NET 10 instalado.

Verificação rápida:

dotnet --version

Como obter e compilar

git clone https://github.com/daniloopinheiro/dopTenEssentialTechNet.git
cd dopTenEssentialTechNet
dotnet restore
dotnet build dopTenEssentialTechNet.sln

Como executar um exemplo

Substitua NomeDoProjeto pelo nome da pasta (por exemplo, SubStringSpan):

dotnet run --project NomeDoProjeto/NomeDoProjeto.csproj

Sugestão de ordem de estudo

Não há ordem obrigatória. Uma sequência possível para quem está estruturando conhecimento:

SubStringSpan e OptionsConfig — fundamentos de performance e configuração.
BackgroundServer — modelo mental de serviços longos.
HTTPolly e Flurl — consumo de HTTP no mundo real.
DynamicDapper e ContextPool — persistência e recursos.
TddContainers — confiança em integração.
VerticalSliceFastEndpoints, WorkflowCore e SourceGeneratedLogging — organização de API, orquestração e ferramentas modernas de logging.

CI/CD e qualidade

O repositório inclui pipelines em .github/workflows/ (build, dependências, monitoramento, deploy e versionamento). Detalhes operacionais estão no README principal e em .github/README_WORKFLOWS.md.

Conclusão

O dopTenEssentialTechNet é um mapa de estudo: cada console é um “capítulo” sobre um pedaço comum do .NET corporativo, em eco à discussão de Gabriel Kohlrausch com Bruno Joaquim e Francisco Schneider sobre o que priorizar em aplicações .NET. Use o repositório para comparar abordagens, extrair trechos para seus próprios sistemas ou acompanhar evoluções de versão do SDK e das bibliotecas.

Conecte-se

Se você trabalha com .NET moderno e quer evoluir em arquitetura, C#, DevOps, APIs e interoperabilidade:

Quando, pois, tiveres comido, e fores farto, louvarás ao Senhor teu Deus pela boa terra que te deu. Deuteronômio 8:10

Construindo API Gateway Tyk utilizando .NET 10

Danilo O. Pinheiro, dopme.io — Mon, 09 Mar 2026 15:22:40 +0000

Construindo API Gateway Tyk utilizando .NET 10

No desenvolvimento de arquiteturas modernas baseadas em microserviços e APIs, o uso de um API Gateway tornou-se praticamente essencial. Ele atua como uma camada intermediária entre clientes e serviços, centralizando segurança, autenticação, monitoramento, versionamento e controle de tráfego.

Uma das soluções que vem ganhando destaque nesse cenário é o https://tyk.io/, uma plataforma open source e cloud-ready para gerenciamento de APIs.

Neste artigo vamos explorar como implementar um API Gateway utilizando Tyk com uma API construída em .NET 10, entendendo os conceitos arquiteturais, configuração do gateway e integração prática.

🧠 O que é um API Gateway?

Um API Gateway é um componente responsável por atuar como ponto único de entrada para múltiplos serviços.

Ele pode oferecer funcionalidades como:

🔐 Autenticação e autorização
📊 Monitoramento e métricas
⚡ Rate limiting
🔁 Balanceamento de carga
🔄 Versionamento de APIs
🧩 Transformação de requests/responses

Em vez de o cliente chamar diretamente vários serviços, ele interage com o gateway, que encaminha as requisições para os serviços corretos.

🏗️ Arquitetura da Solução

Uma arquitetura simples com .NET 10 + Tyk pode ser representada assim:

Cliente
   │
   ▼
API Gateway (Tyk)
   │
   ├── API .NET 10 - Usuários
   ├── API .NET 10 - Produtos
   └── API .NET 10 - Pedidos

Benefícios da abordagem:

Centralização de segurança
Governança de APIs
Observabilidade unificada
Escalabilidade independente

⚙️ Criando a API com .NET 10

Primeiro, vamos criar uma API simples utilizando o CLI do .NET.

📌 Documentação oficial:

https://learn.microsoft.com/dotnet/core/tools/

dotnet new webapi -n ProductApi
cd ProductApi

Execute a aplicação:

dotnet run

Endpoint de exemplo:

app.MapGet("/products", () =>
{
    var products = new[]
    {
        new { Id = 1, Name = "Notebook", Price = 3500 },
        new { Id = 2, Name = "Mouse", Price = 120 }
    };

    return products;
});

A API estará disponível em:

👉 http://localhost:5000/products

🧩 Instalando o Tyk API Gateway

A maneira mais simples de executar o gateway é utilizando Docker.

📌 Documentação oficial do Tyk Gateway:

https://tyk.io/docs/tyk-gateway/

docker run -d \
  -p 8080:8080 \
  tykio/tyk-gateway

Após subir o container, o gateway já estará pronto para configuração.

📦 Criando uma Definição de API no Tyk

O Tyk utiliza arquivos JSON para definir APIs.

Exemplo de configuração:

{
  "name": "Product API",
  "api_id": "product-api",
  "org_id": "default",
  "use_keyless": true,
  "proxy": {
    "listen_path": "/products/",
    "target_url": "http://host.docker.internal:5000/",
    "strip_listen_path": true
  }
}

Explicando os principais campos:

Campo	Descrição
`name`	Nome da API
`api_id`	Identificador único
`use_keyless`	Permite acesso sem chave
`listen_path`	Endpoint exposto no gateway
`target_url`	URL da API real

🔄 Fluxo da Requisição

Cliente
   │
   ▼
http://localhost:8080/products
   │
   ▼
Tyk API Gateway
   │
   ▼
API .NET 10

Ou seja: o cliente não acessa diretamente a API.

🔐 Adicionando Segurança com API Key

Para proteger sua API:

"use_keyless": false

Agora cada requisição deve enviar:

Authorization: Bearer API_KEY

Isso permite:

Controle de acesso
Limite de requisições
Monitoramento por cliente

📌 Documentação:

Authentication

📊 Observabilidade e Monitoramento

O Tyk oferece:

Logs centralizados
Métricas de consumo
Rate limiting
Analytics de API

Esses dados são essenciais em ambientes com:

múltiplos microserviços
alto volume de requisições
integrações com terceiros

🧪 Testando a Integração

Após configurar o gateway, basta chamar:

GET http://localhost:8080/products

Resposta esperada:

[
  { "id": 1, "name": "Notebook", "price": 3500 },
  { "id": 2, "name": "Mouse", "price": 120 }
]

Mesmo resultado da API original — porém agora gerenciado pelo gateway.

⚡ Benefícios de Usar Tyk com .NET

🔹 Escalabilidade
🔹 Segurança centralizada
🔹 Observabilidade robusta
🔹 Governança e versionamento de APIs

🧩 Quando Utilizar um API Gateway

Use um gateway quando:

há múltiplos microserviços
há integração com sistemas externos
é necessário controle de segurança centralizado
existe alto volume de chamadas de API

Em aplicações pequenas, pode ser exagero.

🔮 O Futuro das APIs no .NET

Com a evolução do .NET e da arquitetura baseada em APIs, ferramentas como API Gateways tendem a se tornar cada vez mais comuns.

Plataformas modernas buscam:

Padronização de integração
Segurança centralizada
Observabilidade completa
Redução da complexidade do cliente

O Tyk é uma das opções mais poderosas nesse ecossistema.

✅ Conclusão

A integração entre .NET 10 e o Tyk API Gateway demonstra como arquiteturas modernas podem ser construídas de forma escalável e organizada.

Centralizando segurança, monitoramento e controle de tráfego, o gateway simplifica o desenvolvimento e melhora a governança em ambientes de APIs.

Para equipes que trabalham com microserviços ou integrações complexas, essa abordagem oferece ganhos expressivos de produtividade e confiabilidade.

🤝 Conecte-se Comigo

Se você trabalha com .NET moderno e quer evoluir em temas como arquitetura, C#, DevOps, APIs e interoperabilidade, vamos conversar:

💼 LinkedIn
💻 DEV Community
✍️ Medium
📰 Substack
📧 Email

O norte e o sul tu os criaste; Tabor e Hermom jubilam em teu nome.Tu tens um braço poderoso; forte é a tua mão, e alta está a tua destra.
Salmos 89:12,13

🚀 Que bom que chegou C# 13, Porém o mais novo também C# 14

Danilo O. Pinheiro, dopme.io — Thu, 19 Feb 2026 12:51:28 +0000

O que mudou e como isso impacta seu código no .NET moderno

O C# continua evoluindo de forma incremental, priorizando clareza, segurança, performance e expressividade.
Com a chegada do C# 13 e a evolução para o C# 14, vemos melhorias voltadas principalmente para:

Melhor controle de memória
Redução de boilerplate
Padrões mais expressivos
Maior previsibilidade em código de alto desempenho

Neste artigo, vamos comparar as principais diferenças entre C# 13 e C# 14, com exemplos práticos.

🧠 Visão Geral

Aspecto	C# 13	C# 14
Foco principal	Performance e refinamentos de linguagem	Simplificação e expressividade
Params collections	Melhor suporte	Expandido
Pattern Matching	Melhorias incrementais	Mais expressivo
Ref structs	Mais flexibilidade	Evolução em segurança
Inicialização	Mais controle	Sintaxe ainda mais limpa
Interoperabilidade	Melhorias nativas	Refinamento de cenários low-level

🧩 Principais Novidades do C# 13

1️⃣ Params Collections

Antes do C# 13, params aceitava apenas arrays:

void Print(params string[] values)
{
    foreach (var v in values)
        Console.WriteLine(v);
}

No C# 13, você pode usar outros tipos de coleção como Span<T>:

void Print(params ReadOnlySpan<string> values)
{
    foreach (var v in values)
        Console.WriteLine(v);
}

📌 Benefício:
Melhor performance e menos alocação desnecessária.

2️⃣ Melhorias em `ref struct`

O C# 13 flexibilizou restrições de ref struct, permitindo uso mais amplo em cenários de alta performance.

ref struct BufferProcessor
{
    public void Process() { }
}

📌 Impacto:
Mais controle em cenários de baixo nível e manipulação de memória.

3️⃣ Melhorias em Pattern Matching

C# 13 trouxe pequenos refinamentos em expressões de padrão:

var result = number switch
{
    > 0 and < 10 => "Pequeno",
    >= 10 and < 100 => "Médio",
    _ => "Grande"
};

📌 Código mais legível e expressivo.

🚀 Principais Evoluções do C# 14

O C# 14 continua a linha de simplificação iniciada nas versões anteriores.

1️⃣ Inicialização Mais Simples

Redução adicional de boilerplate em construções comuns.

Antes:

List<int> numbers = new List<int>();

Agora (refinamento):

List<int> numbers = [];

📌 Mais conciso e moderno.

2️⃣ Pattern Matching Mais Poderoso

Expressões ainda mais declarativas:

if (obj is Person { Age: > 18 } person)
{
    Console.WriteLine(person.Name);
}

📌 Melhor leitura sem necessidade de múltiplas verificações.

3️⃣ Melhor Interoperabilidade com Código Nativo

C# 14 aprimora cenários envolvendo:

Span
Memory
Interop com código não gerenciado
Otimizações JIT

Exemplo conceitual:

Span<int> data = stackalloc int[5];

📌 Menos alocação no heap → mais performance.

4️⃣ Melhorias Incrementais em Expressões

Expansão da consistência sintática para manter a linguagem previsível.

🏗️ Impacto Arquitetural

🔹 Para aplicações corporativas

Código mais legível
Menos verbosidade
Menos risco de erro humano

🔹 Para sistemas de alta performance

Melhor controle de memória
Menos alocação desnecessária
Maior previsibilidade

🔹 Para times grandes

Código mais consistente
Melhor padronização
Facilita revisão de código

📊 Comparação Prática

C# 13

void Log(params ReadOnlySpan<string> messages)
{
    foreach (var message in messages)
        Console.WriteLine(message);
}

C# 14

List<string> messages = ["C#", "14", "Evolução"];
Console.WriteLine(string.Join(" ", messages));

Diferença principal:

C# 13 → foco técnico e performance
C# 14 → foco em simplificação e fluidez

🧩 Quando Atualizar?

Vale migrar quando:

✅ O projeto já utiliza .NET 9 ou 10
✅ Há necessidade de melhorias em performance
✅ O time busca código mais moderno e limpo
✅ O projeto é novo

Evite migrar imediatamente se:
⚠️ O projeto é legado e estável
⚠️ Há dependência de ferramentas antigas

🔮 O Caminho do C

A tendência do C# é clara:

Mais expressivo
Menos boilerplate
Mais seguro
Melhor para cloud-native
Melhor para alto desempenho

O foco deixou de ser apenas orientação a objetos e passou a abranger:

Programação funcional
Padrões declarativos
Performance de baixo nível

✅ Conclusão

O C# 13 trouxe melhorias importantes focadas em performance e refinamentos estruturais.
O C# 14 avança na direção de simplificação e consistência sintática, tornando o código ainda mais limpo e intuitivo.

Ambas as versões demonstram maturidade da linguagem e compromisso com produtividade e eficiência.

Para quem trabalha com .NET moderno, acompanhar essas mudanças é essencial para escrever código sustentável e preparado para o futuro.

🤝 Conecte-se Comigo

Se você trabalha com .NET moderno e quer evoluir em temas como arquitetura, C#, DevOps e interoperabilidade, vamos conversar:

💼 LinkedIn
💻 DEV Community
✍️ Medium
📰 Substack
📧 Email

Bendizei, povos, ao nosso Deus, e fazei ouvir a voz do seu louvor. Ao que sustenta com vida a nossa alma, e não consente que sejam abalados os nossos pés. Salmos 66:8,9

Integrando Sentry com .NET

Danilo O. Pinheiro, dopme.io — Wed, 28 Jan 2026 14:20:38 +0000

📖 Introdução

O desenvolvimento de aplicações .NET modernas exige não apenas código funcional, mas também visibilidade completa sobre o comportamento do sistema em produção. Monitoramento, rastreamento de erros e observabilidade tornaram-se componentes essenciais para garantir a confiabilidade e a capacidade de resposta de aplicações críticas.

Este artigo apresenta uma abordagem prática para integrar o Sentry em uma aplicação .NET 8, utilizando Vertical Slice Architecture e padrões modernos como CQRS e MediatR. Demonstraremos como implementar monitoramento robusto, captura automática de exceções e rastreamento contextualizado de eventos.

O projeto dopNetSentry serve como exemplo prático, mostrando como combinar arquitetura limpa, padrões de design e ferramentas de observabilidade para criar soluções profissionais e sustentáveis.

🧱 Visão Geral do Projeto

O dopNetSentry é uma aplicação .NET 8 que demonstra a integração completa do SDK do Sentry para monitoramento e rastreamento automático de erros e exceções. O projeto utiliza uma arquitetura em camadas bem definida:

Api: Camada de apresentação com Minimal APIs
Application: Lógica de aplicação com CQRS (Commands e Queries)
Domain: Entidades de domínio puras
Infrastructure: Persistência e integrações externas

Essa organização permite separação clara de responsabilidades, facilitando testes, manutenção e evolução do sistema.

Características Principais

.NET 8: Utilizando a versão mais recente do framework
Sentry SDK 6.0.0: Monitoramento em tempo real de erros e exceções
Vertical Slice Architecture: Organização por funcionalidade
CQRS com MediatR: Separação entre leitura e escrita
Entity Framework Core: ORM para persistência de dados
FluentValidation: Validação robusta de entrada
Swagger/OpenAPI: Documentação automática da API

🛠️ Componentes Fundamentais

🔹 Arquitetura em Camadas

A aplicação segue o princípio de dependência unidirecional:

Api → Application + Infrastructure
Application → Domain
Infrastructure → Domain + Application

Domain é a camada mais pura, sem dependências externas. Application contém a lógica de negócio e depende apenas de Domain. Infrastructure implementa detalhes técnicos e depende de Domain e Application. Api é a camada de apresentação que orquestra tudo.

🔹 Padrão CQRS (Command Query Responsibility Segregation)

O projeto utiliza MediatR para implementar CQRS:

Commands: Operações de escrita (Create, Update, Delete)
Queries: Operações de leitura (Get, List)
Handlers: Processam Commands e Queries de forma isolada

Essa separação permite otimizações independentes, escalabilidade e clareza no código.

🔹 Vertical Slice Architecture

Ao invés de organizar por camadas técnicas (Controllers, Services, Repositories), o projeto organiza por funcionalidade:

├── src/
│   ├── netsentry.Api/                    # Camada de Apresentação
│   │   ├── Endpoints/
│   │   │   ├── WeatherForecastEndpoints.cs
│   │   │   └── SentryExamplesEndpoints.cs (comentado)
│   │   ├── Exceptions/
│   │   │   └── MyRpcException.cs
│   │   ├── Services/
│   │   │   └── SentryService.cs
│   │   ├── Program.cs
│   │   └── appsettings.json
│   ├── netsentry.Application/            # Camada de Aplicação
│   │   ├── Commands/                     # (vazio - pronto para uso)
│   │   ├── Interfaces/
│   │   │   └── IApplicationDbContext.cs
│   │   ├── Models/
│   │   │   └── WeatherForecastDto.cs
│   │   └── Queries/
│   │       ├── GetWeatherForecastQuery.cs
│   │       └── GetWeatherForecastQueryHandler.cs
│   ├── netsentry.Domain/                 # Camada de Domínio
│   │   └── Entities/
│   │       └── WeatherForecast.cs
│   └── netsentry.Infrastructure/         # Camada de Infraestrutura
│       └── Persistence/
│           └── ApplicationDbContext.cs

Cada funcionalidade contém tudo necessário para sua implementação, promovendo coesão e reduzindo acoplamento.

🔄 Integração com Sentry

Configuração do Sentry

O Sentry é configurado no Program.cs usando o método UseSentry no WebHost:

builder.WebHost.UseSentry(options =>
{
    options.Dsn = builder.Configuration["Sentry:Dsn"];
    options.Debug = true; // Para ver o que o SDK está fazendo
    options.SendDefaultPii = true; // Inclui headers, IP, etc.
    options.TracesSampleRate = 1.0; // 100% das transações
    options.Environment = builder.Environment.EnvironmentName;

    // Filtro de exceções
    options.AddExceptionFilterForType<OperationCanceledException>();

    // Customização de eventos
    options.SetBeforeSend(@event =>
    {
        // Lógica de customização
        return @event;
    });
});

Funcionalidades Implementadas

1. Captura Automática de Exceções

O Sentry captura automaticamente todas as exceções não tratadas. Para exceções tratadas, podemos usar:

try
{
    // Código que pode falhar
}
catch (Exception ex)
{
    SentrySdk.CaptureException(ex);
}

2. Captura de Mensagens

Para registrar eventos informativos:

SentrySdk.CaptureMessage("Operação iniciada", SentryLevel.Info);

3. Configuração de Contexto

Adicionar informações contextuais aos eventos:

SentrySdk.ConfigureScope(scope =>
{
    scope.SetTag("endpoint", "weatherforecast");
    scope.SetTag("method", "GET");
    scope.SetExtra("request-time", DateTime.UtcNow.ToString("O"));
});

4. Filtros de Exceção

Ignorar tipos específicos de exceções:

options.AddExceptionFilterForType<OperationCanceledException>();

5. Customização com SetBeforeSend

Modificar eventos antes de enviar ao Sentry:

options.SetBeforeSend(@event =>
{
    if (@event.Exception is MyRpcException rpcEx)
    {
        @event.SetFingerprint(new[]
        {
            "{{ default }}",
            rpcEx.Function,
            rpcEx.Code.ToString(),
        });
    }
    return @event;
});

Exemplo Prático: Endpoint WeatherForecast

O endpoint /weatherforecast demonstra a integração completa:

group.MapGet("/", async (IMediator mediator, CancellationToken cancellationToken) =>
{
    try
    {
        // Configurar contexto
        SentrySdk.ConfigureScope(scope =>
        {
            scope.SetTag("endpoint", "weatherforecast");
            scope.SetTag("method", "GET");
        });

        // Log de início
        SentrySdk.CaptureMessage("Iniciando busca de previsão do tempo", SentryLevel.Info);

        var query = new GetWeatherForecastQuery();
        var result = await mediator.Send(query, cancellationToken);

        return Results.Ok(result);
    }
    catch (Exception ex)
    {
        // Captura com contexto adicional
        SentrySdk.ConfigureScope(scope =>
        {
            scope.SetTag("error-type", ex.GetType().Name);
            scope.SetExtra("error-message", ex.Message);
            scope.Level = SentryLevel.Error;
        });

        SentrySdk.CaptureException(ex);
        return Results.Problem(statusCode: 500);
    }
});

🧪 Testes e Qualidade

A arquitetura implementada facilita a criação de testes:

Testes Unitários: Handlers podem ser testados isoladamente com mocks
Testes de Integração: Endpoints podem ser testados com banco em memória
Testes de Observabilidade: Verificar se eventos são enviados corretamente ao Sentry

A separação de responsabilidades permite isolar dependências e criar testes rápidos e confiáveis.

📊 Observabilidade e Operação

O Sentry fornece:

Monitoramento de Erros em Tempo Real: Notificações instantâneas quando erros ocorrem
Stack Traces Completos: Veja exatamente onde e por que os erros acontecem
Contexto Rico: Informações sobre usuários afetados, ambiente, versão da aplicação
Performance Insights: Identifique gargalos e otimize a performance
Dashboard Interativo: Visualize estatísticas e tendências

Como Obter o DSN do Sentry

Para utilizar o Sentry em sua aplicação, você precisa criar uma conta no Sentry.io e obter o DSN (Data Source Name) do seu projeto. Siga os passos abaixo:

Criar uma Conta no Sentry.io
- Acesse https://sentry.io/signup/
- Crie uma conta gratuita (o plano gratuito oferece recursos suficientes para começar)
- Confirme seu email se necessário
Criar uma Organização e Projeto
- Após fazer login, você será direcionado para criar uma organização
- Escolha um nome para sua organização
- Crie um novo projeto selecionando a plataforma .NET
- Escolha um nome para o projeto (ex: "dopNetSentry")
Obter o DSN
- Após criar o projeto, o Sentry exibirá uma tela de configuração
- O DSN estará visível no formato: https://[chave]@[organização].ingest.sentry.io/[projeto-id]
- Você também pode encontrar o DSN posteriormente em: Settings → Projects → [Seu Projeto] → Client Keys (DSN)
Copiar o DSN
- Copie o DSN completo fornecido pelo Sentry
- Este será o valor que você configurará no appsettings.json

Nota: O DSN é uma chave pública que identifica seu projeto no Sentry. Embora seja seguro incluí-lo no código-fonte, é recomendado usar variáveis de ambiente ou Azure Key Vault em produção.

Configuração via appsettings.json

Após obter o DSN, configure-o no arquivo appsettings.json:

{
  "Sentry": {
    "Dsn": "https://[sua-chave]@[seu-org].ingest.sentry.io/[projeto-id]",
    "Debug": true,
    "SendDefaultPii": true,
    "TracesSampleRate": 1.0,
    "Environment": "Development"
  }
}

Substitua o valor de Dsn pelo DSN real obtido na sua conta do Sentry.

Boas Práticas

Não inclua dados sensíveis nos logs ou contexto do Sentry
Use filtros para ignorar exceções esperadas (como OperationCanceledException)
Configure ambientes diferentes (Development, Staging, Production)
Ajuste TracesSampleRate em produção para controlar volume
Desative Debug em produção para melhor performance

🔐 Segurança

O projeto implementa várias práticas de segurança:

Validação de Entrada: FluentValidation valida todos os dados de entrada
Parameterized Queries: Entity Framework Core usa queries parametrizadas automaticamente
Object Level Authorization: Verificação de permissões em endpoints
Logging Seguro: Não inclui dados sensíveis nos logs
Configuração Segura: DSN do Sentry via configuração, não hardcoded

Essas práticas garantem que a aplicação seja robusta e segura.

🚧 Evolução e Sustentabilidade

A arquitetura escolhida permite:

Evolução Incremental: Adicionar novas funcionalidades sem impactar existentes
Manutenibilidade: Código organizado e fácil de entender
Escalabilidade: Estrutura preparada para crescimento
Testabilidade: Fácil de testar e validar

A Vertical Slice Architecture promove coesão alta e acoplamento baixo, facilitando a evolução contínua do sistema.

✅ Conclusão

A integração do Sentry em aplicações .NET 8, combinada com uma arquitetura bem definida, proporciona:

Visibilidade Completa: Entenda o que acontece em produção
Resposta Rápida: Identifique e corrija problemas rapidamente
Confiança: Monitore a saúde da aplicação continuamente
Melhoria Contínua: Use dados reais para otimizar o sistema

O projeto dopNetSentry demonstra como combinar tecnologias modernas (.NET 8, Sentry) com padrões arquiteturais sólidos (Vertical Slice, CQRS) para criar aplicações profissionais, observáveis e sustentáveis.

Tecnologias mudam, mas bons fundamentos permanecem.

📚 Recursos Adicionais

🤝 Conecte-se Comigo

Se você trabalha com .NET moderno e quer dominar arquitetura, C#, DevOps ou interoperabilidade, vamos conversar:

💼 LinkedIn

💻 DEV Community

✍️ Medium

📰 Substack

📧 Email

Projeto: dopNetSentry

Versão: 1.0.0

Data: Janeiro 2025

³ Porque assim diz o Senhor aos homens de Judá e a Jerusalém: Preparai para vós o campo de lavoura, e não semeeis entre espinhos. Jeremias 4:3

🚀 Desenvolvimento Full-Stack Moderno: TanStack Router + .NET

Danilo O. Pinheiro, dopme.io — Wed, 21 Jan 2026 19:13:41 +0000

✨ Construindo Aplicações Web Escaláveis com Type-Safe Routing e APIs RESTful

No cenário atual de desenvolvimento de software, a necessidade de criar aplicações web modernas, escaláveis e com excelente experiência do desenvolvedor é cada vez mais crítica. Este artigo apresenta uma abordagem prática para construir aplicações full-stack utilizando React com TanStack Router no frontend e ASP.NET Core no backend, demonstrando como essas tecnologias se complementam para criar soluções robustas e type-safe.

📖 Introdução

O desenvolvimento de aplicações web modernas exige uma combinação harmoniosa entre frontend e backend, onde cada camada deve ser construída com as melhores ferramentas disponíveis. Enquanto o ecossistema JavaScript/TypeScript domina o frontend com frameworks como React, o .NET continua sendo uma das plataformas mais robustas para construção de APIs e serviços backend.

Este artigo aborda a integração entre TanStack Router — uma solução moderna de roteamento type-safe para React — e ASP.NET Core, demonstrando como criar uma arquitetura full-stack que prioriza type safety, performance e manutenibilidade. Você aprenderá a configurar um projeto completo, desde a estrutura inicial até a implementação de rotas, APIs e integração entre as camadas.

🎯 Objetivo do Artigo

Ao final deste artigo, você será capaz de:

Entender os conceitos fundamentais de roteamento type-safe com TanStack Router e construção de APIs RESTful com ASP.NET Core
Conhecer boas práticas no ecossistema .NET moderno, incluindo configuração de CORS, documentação de APIs e estruturação de projetos
Aplicar o conhecimento em cenários reais através de um projeto prático que demonstra a integração completa entre frontend e backend
Evitar erros comuns de implementação, como problemas de CORS, configuração incorreta de rotas SPA e falta de type safety

🧠 Conceitos Fundamentais

TanStack Router: Roteamento Type-Safe

TanStack Router é uma biblioteca de roteamento para React que prioriza type safety e developer experience. Diferente de soluções tradicionais como React Router, o TanStack Router oferece:

Type Safety Completo: As rotas são tipadas em tempo de compilação, prevenindo erros comuns de navegação
Code Splitting Automático: Divisão automática de código para otimização de performance
File-Based Routing: Sistema de rotas baseado em arquivos, similar ao Next.js, mas com mais flexibilidade
Data Loading Integrado: Suporte nativo para carregamento de dados com estados de loading e erro

ASP.NET Core: Framework Moderno para APIs

ASP.NET Core é o framework web da Microsoft para construção de aplicações modernas:

Multiplataforma: Roda em Windows, Linux e macOS
Alto Desempenho: Um dos frameworks web mais rápidos disponíveis
Minimal APIs: Sintaxe simplificada para criação de endpoints
Integração Nativa: Suporte completo para JSON, CORS, autenticação e muito mais

Type Safety no Full-Stack

A type safety não deve ser limitada ao frontend. Ao usar TypeScript no React e C# no backend, garantimos:

Contratos Claros: Interfaces e DTOs bem definidos entre frontend e backend
Detecção Precoce de Erros: Problemas identificados em tempo de compilação
Melhor Autocomplete: IDEs fornecem sugestões precisas em ambas as camadas
Refatoração Segura: Mudanças podem ser feitas com confiança

🏗️ Arquitetura e Estrutura

Visão Geral da Arquitetura

┌─────────────────────────────────────────────────────────┐
│                    Frontend (React)                     │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐   │
│  │   TanStack   │  │  Components  │  │   State      │   │
│  │    Router    │  │   (React)    │  │  Management  │   │
│  └──────────────┘  └──────────────┘  └──────────────┘   │
│                          │                              │
│                          │ HTTP/REST                    │
└──────────────────────────┼──────────────────────────────┘
                           │
┌──────────────────────────┼──────────────────────────────┐
│                    Backend (.NET)                       │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐   │
│  │  Controllers │  │   Services   │  │   Data       │   │
│  │   (API)      │  │   (Business) │  │   Access     │   │
│  └──────────────┘  └──────────────┘  └──────────────┘   │
└─────────────────────────────────────────────────────────┘

Organização de Camadas

Frontend (React + TanStack Router)

src/
├── routes/              # Rotas baseadas em arquivos
│   ├── __root.tsx      # Rota raiz (layout principal)
│   ├── index.tsx       # Página inicial (/)
│   ├── about.tsx       # Página sobre (/about)
│   └── api-example.tsx # Exemplo de integração (/api-example)
├── components/          # Componentes reutilizáveis
├── hooks/              # Custom hooks
├── utils/              # Funções utilitárias
└── main.tsx           # Ponto de entrada

Princípios de Organização:

File-Based Routing: Cada arquivo em routes/ representa uma rota
Co-location: Componentes relacionados ficam próximos às rotas
Separação de Responsabilidades: Lógica de negócio separada de apresentação

Backend (ASP.NET Core)

NetTanstack.Api/
├── Controllers/        # Controladores da API
│   └── WeatherForecastController.cs
├── Services/          # Serviços de negócio
├── Models/            # Modelos e DTOs
├── Program.cs         # Configuração e pipeline
└── appsettings.json   # Configurações

Princípios de Organização:

Controller-Based: Organização por recursos/funcionalidades
Dependency Injection: Uso extensivo de DI para desacoplamento
Minimal APIs: Endpoints simples podem usar Minimal APIs

Comunicação entre Componentes

Frontend → Backend: Requisições HTTP via fetch ou bibliotecas como Axios
Backend → Frontend: Respostas JSON tipadas
Type Safety: Contratos definidos em TypeScript (frontend) e C# (backend)

Impactos em Escalabilidade e Manutenção

Escalabilidade Horizontal: Backend pode ser escalado independentemente
Deploy Independente: Frontend e backend podem ser deployados separadamente
Manutenibilidade: Código organizado e type-safe facilita manutenção
Testabilidade: Separação clara permite testes isolados

🛠️ Implementação no .NET

Estrutura de Projeto

1. Configuração do Backend (ASP.NET Core)

// Program.cs
var builder = WebApplication.CreateBuilder(args);

// Adicionar serviços
builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

// Configurar CORS para permitir requisições do frontend
builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowReactApp", policy =>
    {
        policy.WithOrigins("http://localhost:5173")
              .AllowAnyHeader()
              .AllowAnyMethod();
    });
});

var app = builder.Build();

// Configurar pipeline
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseCors("AllowReactApp");
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();

// Exemplo de Minimal API
app.MapGet("/api/hello", () => new { message = "Olá do backend .NET!" })
   .WithName("Hello");

app.Run();

Por que essas decisões?

CORS Configurado: Permite comunicação entre frontend e backend em desenvolvimento
Swagger em Desenvolvimento: Facilita testes e documentação da API
Minimal APIs: Sintaxe mais limpa para endpoints simples
Controllers: Melhor para endpoints mais complexos com múltiplas ações

2. Exemplo de Controller

// Controllers/WeatherForecastController.cs
[ApiController]
[Route("api/[controller]")]
public class WeatherForecastController : ControllerBase
{
    private static readonly string[] Summaries = new[]
    {
        "Congelante", "Frio", "Fresco", "Ameno", "Quente", "Tropical", "Escaldante"
    };

    [HttpGet]
    public IEnumerable<WeatherForecast> Get()
    {
        return Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
        })
        .ToArray();
    }
}

public record WeatherForecast
{
    public DateOnly Date { get; set; }
    public int TemperatureC { get; set; }
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    public string? Summary { get; set; }
}

Boas Práticas Aplicadas:

Records para DTOs: Sintaxe concisa e imutabilidade por padrão
Atributos de Roteamento: [ApiController] e [Route] para convenções claras
Separação de Responsabilidades: Controller apenas coordena, lógica em serviços (em projetos maiores)

Configuração do Frontend (React + TanStack Router)

1. Configuração do Vite

// vite.config.ts
import { defineConfig, type Plugin } from 'vite'
import react from '@vitejs/plugin-react'
import { tanstackRouter } from '@tanstack/router-plugin/vite'
import type { IncomingMessage, ServerResponse } from 'node:http'
import type { NextFunction } from 'node:connect'

// Plugin para garantir fallback para index.html em todas as rotas (SPA)
const spaFallback = (): Plugin => {
  return {
    name: 'spa-fallback',
    configureServer(server) {
      return () => {
        server.middlewares.use((req: IncomingMessage, res: ServerResponse, next: NextFunction) => {
          if (
            req.url &&
            !req.url.startsWith('/api') &&
            !req.url.includes('.') &&
            req.url !== '/'
          ) {
            req.url = '/index.html'
          }
          next()
        })
      }
    },
  }
}

export default defineConfig({
  plugins: [
    tanstackRouter({
      target: 'react',
      autoCodeSplitting: true,
    }),
    react(),
    spaFallback(),
  ],
  server: {
    port: 5173,
    proxy: {
      '/api': {
        target: 'http://localhost:5000',
        changeOrigin: true,
      },
    },
  },
})

Decisões Técnicas:

Plugin SPA Fallback: Garante que recarregar qualquer rota funcione corretamente
Proxy para API: Redireciona /api/* para o backend, evitando problemas de CORS em desenvolvimento
Auto Code Splitting: TanStack Router divide automaticamente o código por rota

2. Estrutura de Rotas

// src/routes/__root.tsx
import { createRootRoute, Link, Outlet } from '@tanstack/react-router'
import { TanStackRouterDevtools } from '@tanstack/react-router-devtools'

const RootLayout = () => (
  <>
    <nav className="main-nav">
      <div className="nav-container">
        <Link to="/" className="nav-link [&.active]:font-bold">
          Home
        </Link>
        <Link to="/about" className="nav-link [&.active]:font-bold">
          Sobre
        </Link>
        <Link to="/api-example" className="nav-link [&.active]:font-bold">
          API Example
        </Link>
      </div>
    </nav>
    <main className="main-content">
      <Outlet />
    </main>
    <TanStackRouterDevtools />
  </>
)

export const Route = createRootRoute({ component: RootLayout })

// src/routes/api-example.tsx
import { createFileRoute } from '@tanstack/react-router'
import { useState, useEffect } from 'react'

export const Route = createFileRoute('/api-example')({
  component: ApiExample,
})

interface WeatherForecast {
  date: string
  temperatureC: number
  temperatureF: number
  summary: string
}

function ApiExample() {
  const [data, setData] = useState<WeatherForecast[]>([])
  const [loading, setLoading] = useState(true)
  const [error, setError] = useState<string | null>(null)

  useEffect(() => {
    const fetchData = async () => {
      try {
        setLoading(true)
        const response = await fetch('/api/weatherforecast')
        if (!response.ok) {
          throw new Error('Erro ao buscar dados')
        }
        const result = await response.json()
        setData(result)
        setError(null)
      } catch (err) {
        setError(err instanceof Error ? err.message : 'Erro desconhecido')
      } finally {
        setLoading(false)
      }
    }

    fetchData()
  }, [])

  return (
    <div className="page-container">
      {/* UI do componente */}
    </div>
  )
}

Por que essa abordagem?

File-Based Routing: Rotas definidas por arquivos, facilitando navegação e manutenção
Type Safety: Interface WeatherForecast garante que os dados da API sejam tipados
Error Handling: Tratamento adequado de erros e estados de loading
Separation of Concerns: Lógica de fetch separada da apresentação

🔄 Boas Práticas e Cuidados

1. Evitar Acoplamento Excessivo

❌ Ruim:

// Frontend conhece detalhes de implementação do backend
const response = await fetch('http://localhost:5000/api/weatherforecast')
const data = await response.json()
// Sem validação de tipos

✅ Bom:

// Abstração através de serviços
import { weatherService } from '@/services/weather'

const data = await weatherService.getForecast()
// Tipos garantidos, fácil de mockar em testes

2. Garantir Testabilidade

Backend:

Use Dependency Injection para todos os serviços
Separe lógica de negócio dos controllers
Crie interfaces para dependências externas

Frontend:

Extraia lógica de fetch para hooks customizados
Use serviços para comunicação com API
Facilite mocking em testes

3. Pensar em Observabilidade

// Adicionar logging estruturado
builder.Services.AddLogging(builder =>
{
    builder.AddConsole();
    builder.AddSeq(); // Ou outro sistema de logging
});

// Logar requisições importantes
_logger.LogInformation("Weather forecast requested at {Time}", DateTime.UtcNow);

4. Tratar Falhas e Exceções Corretamente

Backend:

// Middleware global de tratamento de exceções
app.UseExceptionHandler(appBuilder =>
{
    appBuilder.Run(async context =>
    {
        context.Response.StatusCode = 500;
        context.Response.ContentType = "application/json";

        var exception = context.Features.Get<IExceptionHandlerFeature>();
        if (exception != null)
        {
            await context.Response.WriteAsync(JsonSerializer.Serialize(new
            {
                error = "An error occurred",
                message = exception.Error.Message
            }));
        }
    });
});

Frontend:

// Tratamento consistente de erros
try {
  const data = await fetch('/api/weatherforecast')
  if (!data.ok) {
    throw new Error(`HTTP error! status: ${data.status}`)
  }
  // processar dados
} catch (error) {
  // Logar erro e mostrar mensagem amigável ao usuário
  console.error('Failed to fetch weather data:', error)
  setError('Não foi possível carregar os dados. Tente novamente.')
}

5. Considerar Segurança desde o Início

CORS: Configure apenas origens necessárias em produção
Validação de Input: Sempre valide dados recebidos
HTTPS: Force HTTPS em produção
Rate Limiting: Implemente limites de requisição
Autenticação: Use JWT ou OAuth2 para APIs protegidas

// CORS mais restritivo em produção
if (app.Environment.IsProduction())
{
    builder.Services.AddCors(options =>
    {
        options.AddPolicy("AllowReactApp", policy =>
        {
            policy.WithOrigins("https://meudominio.com")
                  .AllowAnyHeader()
                  .AllowAnyMethod()
                  .AllowCredentials();
        });
    });
}

📊 Benefícios da Abordagem

Código Mais Limpo e Organizado

Type Safety: Erros detectados em tempo de compilação
Estrutura Clara: File-based routing facilita navegação
Convenções: Padrões consistentes reduzem decisões arbitrárias

Facilidade de Manutenção

Separação de Responsabilidades: Frontend e backend independentes
Refatoração Segura: TypeScript e C# permitem refatorações com confiança
Documentação: Swagger gera documentação automática da API

Escalabilidade

Deploy Independente: Escalar frontend e backend separadamente
Performance: Code splitting automático otimiza carregamento
Arquitetura Flexível: Fácil adicionar novos serviços ou features

Melhor Experiência para Times de Desenvolvimento

Developer Experience: Autocomplete preciso, erros claros
Hot Reload: Mudanças refletidas instantaneamente
DevTools: TanStack Router DevTools facilitam debug

Menor Risco em Produção

Type Safety: Previne erros de runtime
Testabilidade: Código testável por design
Observabilidade: Logging e monitoramento facilitados

🚧 Desafios Comuns

1. Complexidade Desnecessária

Problema: Adicionar muitas camadas e abstrações sem necessidade real.

Solução: Comece simples. Adicione complexidade apenas quando necessário. Um controller direto pode ser suficiente para APIs simples.

2. Uso Incorreto de Ferramentas

Problema: Usar TanStack Router para aplicações muito simples onde React Router seria suficiente.

Solução: Avalie as necessidades do projeto. TanStack Router brilha em aplicações complexas com muitas rotas e necessidade de type safety.

3. Falta de Padronização

Problema: Diferentes padrões de nomenclatura, estrutura de pastas e estilos de código.

Solução: Estabeleça convenções desde o início e documente-as. Use ferramentas como ESLint e EditorConfig para manter consistência.

4. Dificuldade de Evolução sem Refatoração

Problema: Código acoplado dificulta adicionar novas features.

Solução:

Use Dependency Injection
Separe lógica de negócio de apresentação
Crie interfaces para dependências
Escreva testes que facilitem refatoração

5. Problemas de CORS em Produção

Problema: Configuração de CORS muito permissiva ou incorreta.

Solução: Configure CORS específico para cada ambiente. Em produção, liste apenas origens necessárias.

✅ Conclusão

Este artigo apresentou uma abordagem prática para construir aplicações full-stack modernas utilizando React com TanStack Router no frontend e ASP.NET Core no backend. Através da combinação dessas tecnologias, conseguimos criar soluções que priorizam type safety, performance e manutenibilidade.

Os principais pontos abordados foram:

Conceitos fundamentais de roteamento type-safe e construção de APIs RESTful
Arquitetura moderna com separação clara de responsabilidades
Implementação prática com exemplos de código reais
Boas práticas para garantir qualidade e sustentabilidade
Desafios comuns e como evitá-los

A escolha de tecnologias modernas como TanStack Router e ASP.NET Core, combinada com boas práticas de arquitetura, resulta em aplicações mais robustas, escaláveis e fáceis de manter. A type safety em ambas as camadas (TypeScript e C#) reduz significativamente erros em runtime e melhora a experiência de desenvolvimento.

É importante lembrar que boas decisões arquiteturais e técnicas impactam diretamente a qualidade, a escalabilidade e a longevidade das aplicações. Investir tempo em estruturação adequada e escolha de ferramentas apropriadas paga dividendos a longo prazo.

Próximos Passos:

Experimente o projeto de exemplo e adapte para suas necessidades
Explore recursos avançados do TanStack Router como data loading e route masking
Implemente autenticação e autorização na API
Adicione testes unitários e de integração
Configure CI/CD para deploy automatizado

Aplique esses conceitos de forma gradual e consciente, sempre avaliando as necessidades específicas do seu projeto. Comece simples e evolua conforme a complexidade aumenta.

🤝 Conecte-se Comigo

Se você trabalha com .NET moderno e quer dominar arquitetura, C#, DevOps ou interoperabilidade, vamos conversar:

💼 LinkedIn

💻 Dev.to

✍️ Medium

✍️ Substack

📬 Email

Referências e Recursos:

Adeus, Swagger UI ? Uma alternativa elegante com Redoc

Danilo O. Pinheiro, dopme.io — Sat, 10 Jan 2026 17:06:46 +0000

Neste artigo, vamos explorar como criar uma API RESTful completa em .NET 8 usando Minimal APIs, implementando um CRUD (Create, Read, Update, Delete) completo para cadastro de pessoas. Além disso, vamos integrar OpenAPI/Swagger para documentação automática e Redoc para uma interface de documentação interativa e elegante.

O projeto demonstra as melhores práticas modernas de desenvolvimento .NET, incluindo:

Minimal APIs para endpoints limpos e diretos
Validação de dados com Data Annotations
Documentação automática com OpenAPI 3.0
Interface de documentação com Redoc
Arquitetura em camadas com serviços e modelos separados

🛠️ Tecnologias Utilizadas

.NET 8.0 - Framework moderno e de alto desempenho
Minimal APIs - Abordagem simplificada para criar APIs REST
Swashbuckle.AspNetCore - Geração automática de documentação OpenAPI/Swagger
Redoc - Interface de documentação interativa e elegante
Data Annotations - Validação de dados nativa do .NET

📁 Estrutura do Projeto

NR.Api/
├── Models/
│   ├── Pessoa.cs                  # Modelo de domínio
│   ├── CriarPessoaRequest.cs      # DTO para criação
│   └── AtualizarPessoaRequest.cs  # DTO para atualização
├── Services/
│   ├── IPessoaService.cs          # Interface do serviço
│   └── PessoaService.cs           # Implementação do serviço (em memória)
├── Properties/
│   └── launchSettings.json        # Configurações de execução
├── wwwroot/
│   ├── index.html                 # Página inicial
│   └── redoc.html                 # Interface Redoc
├── Program.cs                     # Configuração e endpoints
└── NR.Api.csproj                  # Arquivo do projeto

🚀 Como Executar o Projeto

Pré-requisitos

.NET 8 SDK instalado
Visual Studio 2022, VS Code ou Rider (opcional)

Passos para Executar

Clone ou navegue até o diretório do projeto

cd NR.Api

Restaura as dependências

dotnet restore

Execute a aplicação

dotnet run

Acesse a documentação

Redoc: http://localhost:5059/
Swagger UI: http://localhost:5059/swagger (apenas em Development)

📚 Modelos de Dados

Pessoa (Modelo de Domínio)

public class Pessoa
{
    public Guid Id { get; set; }
    public string Nome { get; set; } = string.Empty;
    public string Email { get; set; } = string.Empty;
    public string Telefone { get; set; } = string.Empty;
    public DateTime DataNascimento { get; set; }
    public string? Endereco { get; set; }
    public DateTime DataCriacao { get; set; }
    public DateTime? DataAtualizacao { get; set; }
}

CriarPessoaRequest (DTO de Criação)

public class CriarPessoaRequest
{
    [Required(ErrorMessage = "O nome é obrigatório")]
    [StringLength(200, MinimumLength = 2)]
    public string Nome { get; set; } = string.Empty;

    [Required(ErrorMessage = "O email é obrigatório")]
    [EmailAddress(ErrorMessage = "O email deve ser válido")]
    public string Email { get; set; } = string.Empty;

    [Required(ErrorMessage = "O telefone é obrigatório")]
    [StringLength(20, MinimumLength = 10)]
    public string Telefone { get; set; } = string.Empty;

    [Required(ErrorMessage = "A data de nascimento é obrigatória")]
    public DateTime DataNascimento { get; set; }

    [StringLength(500)]
    public string? Endereco { get; set; }
}

AtualizarPessoaRequest (DTO de Atualização)

Similar ao CriarPessoaRequest, usado para atualização de dados.

🔌 Endpoints da API

1. Health Check

GET /health

Retorna o status de saúde da aplicação.

Resposta:

{
  "status": "healthy",
  "timestamp": "2024-01-09T10:30:00Z",
  "version": "1.0.0"
}

2. Listar Todas as Pessoas

GET /api/pessoas

Retorna uma lista com todas as pessoas cadastradas.

Resposta (200 OK):

[
  {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "nome": "João Silva",
    "email": "joao.silva@email.com",
    "telefone": "(11) 98765-4321",
    "dataNascimento": "1990-05-15T00:00:00Z",
    "endereco": "Rua Exemplo, 123",
    "dataCriacao": "2024-01-09T10:00:00Z",
    "dataAtualizacao": null
  }
]

3. Obter Pessoa por ID

GET /api/pessoas/{id}

Retorna os dados de uma pessoa específica.

Parâmetros:

id (Guid): ID único da pessoa

Resposta (200 OK):

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "nome": "João Silva",
  "email": "joao.silva@email.com",
  "telefone": "(11) 98765-4321",
  "dataNascimento": "1990-05-15T00:00:00Z",
  "endereco": "Rua Exemplo, 123",
  "dataCriacao": "2024-01-09T10:00:00Z",
  "dataAtualizacao": null
}

Resposta (404 Not Found):

{
  "message": "Pessoa com ID {id} não encontrada"
}

4. Criar Nova Pessoa

POST /api/pessoas

Cria uma nova pessoa no sistema.

Body (JSON):

{
  "nome": "Maria Santos",
  "email": "maria.santos@email.com",
  "telefone": "(11) 91234-5678",
  "dataNascimento": "1985-08-20",
  "endereco": "Avenida Principal, 456"
}

Resposta (201 Created):

{
  "id": "660e8400-e29b-41d4-a716-446655440001",
  "nome": "Maria Santos",
  "email": "maria.santos@email.com",
  "telefone": "(11) 91234-5678",
  "dataNascimento": "1985-08-20T00:00:00Z",
  "endereco": "Avenida Principal, 456",
  "dataCriacao": "2024-01-09T10:15:00Z",
  "dataAtualizacao": null
}

Resposta (400 Bad Request):

{
  "errors": [
    "O nome é obrigatório",
    "O email deve ser válido"
  ]
}

5. Atualizar Pessoa

PUT /api/pessoas/{id}

Atualiza os dados de uma pessoa existente.

Parâmetros:

id (Guid): ID único da pessoa

Body (JSON):

{
  "nome": "Maria Santos Silva",
  "email": "maria.silva@email.com",
  "telefone": "(11) 91234-5678",
  "dataNascimento": "1985-08-20",
  "endereco": "Avenida Principal, 456 - Apto 101"
}

Resposta (200 OK):

{
  "id": "660e8400-e29b-41d4-a716-446655440001",
  "nome": "Maria Santos Silva",
  "email": "maria.silva@email.com",
  "telefone": "(11) 91234-5678",
  "dataNascimento": "1985-08-20T00:00:00Z",
  "endereco": "Avenida Principal, 456 - Apto 101",
  "dataCriacao": "2024-01-09T10:15:00Z",
  "dataAtualizacao": "2024-01-09T10:20:00Z"
}

6. Deletar Pessoa

DELETE /api/pessoas/{id}

Remove uma pessoa do sistema.

Parâmetros:

id (Guid): ID único da pessoa

Resposta (204 No Content): Sem corpo de resposta

Resposta (404 Not Found):

{
  "message": "Pessoa com ID {id} não encontrada"
}

💻 Implementação do Serviço

O serviço PessoaService utiliza um dicionário em memória para armazenar os dados. Em uma aplicação de produção, você substituiria isso por um banco de dados (SQL Server, PostgreSQL, MongoDB, etc.).

public class PessoaService : IPessoaService
{
    private readonly Dictionary<Guid, Pessoa> _pessoas = new();
    private readonly object _lock = new();

    public Task<Pessoa> CriarAsync(CriarPessoaRequest request)
    {
        lock (_lock)
        {
            var pessoa = new Pessoa
            {
                Id = Guid.NewGuid(),
                Nome = request.Nome,
                Email = request.Email,
                Telefone = request.Telefone,
                DataNascimento = request.DataNascimento,
                Endereco = request.Endereco,
                DataCriacao = DateTime.UtcNow
            };

            _pessoas[pessoa.Id] = pessoa;
            return Task.FromResult(pessoa);
        }
    }

    // ... outros métodos
}

✅ Validação de Dados

O projeto utiliza Data Annotations para validação de dados. As validações incluem:

Required: Campos obrigatórios
EmailAddress: Validação de formato de email
StringLength: Limitação de tamanho de strings
MinimumLength: Tamanho mínimo de strings

Exemplo de validação no endpoint:

var validationResults = new List<ValidationResult>();
var validationContext = new ValidationContext(request);

if (!Validator.TryValidateObject(request, validationContext, validationResults, true))
{
    return Results.BadRequest(new { errors = validationResults.Select(v => v.ErrorMessage) });
}

🧪 Testando a API

Usando cURL

Listar pessoas:

curl -X GET http://localhost:5059/api/pessoas

Criar pessoa:

curl -X POST http://localhost:5059/api/pessoas \
  -H "Content-Type: application/json" \
  -d '{
    "nome": "João Silva",
    "email": "joao.silva@email.com",
    "telefone": "(11) 98765-4321",
    "dataNascimento": "1990-05-15",
    "endereco": "Rua Exemplo, 123"
  }'

Atualizar pessoa:

curl -X PUT http://localhost:5059/api/pessoas/{id} \
  -H "Content-Type: application/json" \
  -d '{
    "nome": "João Silva Santos",
    "email": "joao.santos@email.com",
    "telefone": "(11) 98765-4321",
    "dataNascimento": "1990-05-15",
    "endereco": "Rua Exemplo, 123"
  }'

Deletar pessoa:

curl -X DELETE http://localhost:5059/api/pessoas/{id}

Usando Postman ou Insomnia

Importe a especificação OpenAPI disponível em /swagger/v1/swagger.json no Postman ou Insomnia para ter acesso a todos os endpoints pré-configurados.

🎨 Documentação com OpenAPI e Redoc

OpenAPI/Swagger

O projeto utiliza Swashbuckle.AspNetCore para gerar automaticamente a documentação OpenAPI 3.0. A especificação OpenAPI está disponível em:

JSON: http://localhost:5059/swagger/v1/swagger.json
Swagger UI: http://localhost:5059/swagger (apenas em Development)

Gerando HTML Estático com Redocly CLI para Produção

Para ambiente de produção, é recomendado gerar uma versão estática da documentação usando o Redocly CLI. Isso oferece melhor performance e pode ser servido por qualquer servidor web estático.

Passo A — Instalar Redocly CLI (Node)

Primeiro, instale o Redocly CLI globalmente usando npm:

npm install -g @redocly/cli

Nota: É necessário ter o Node.js instalado em sua máquina. Você pode baixá-lo em nodejs.org.

Passo B — Gerar o OpenAPI JSON localmente

Com a API rodando, baixe o arquivo JSON da especificação OpenAPI:

curl http://localhost:5059/swagger/v1/swagger.json -o openapi.json

Ou, no Windows PowerShell:

Invoke-WebRequest -Uri http://localhost:5059/swagger/v1/swagger.json -OutFile openapi.json

Passo C — Gerar o HTML do Redoc

Execute o comando para gerar o HTML estático:

redocly build-docs openapi.json

Isso cria um arquivo redoc-static.html no diretório atual.

Passo D — Colocar o HTML no wwwroot

Agora você pode mover o arquivo gerado para o diretório wwwroot e servi-lo diretamente:

mkdir -p wwwroot
mv redoc-static.html wwwroot/index.html

Ou, no Windows PowerShell:

New-Item -ItemType Directory -Force -Path wwwroot
Move-Item -Path redoc-static.html -Destination wwwroot/index.html

Agora abra http://localhost:5059/index.html para ver a documentação estática.

Vantagens do Redocly CLI

✅ Configuração personalizada: Diferentes opções de configuração e temas
✅ Lint e validação: Valida a especificação OpenAPI antes de gerar
✅ Bundle da spec: Consolida referências externas em um único arquivo
✅ Builds automatizados: Integra facilmente em pipelines de CI/CD
✅ Deploy estático: Pode ser servido por qualquer servidor web estático (Nginx, Azure Static Web Apps, GitHub Pages, etc.)
✅ Melhor performance: HTML estático carrega mais rápido que versões dinâmicas

Exemplo de Configuração Avançada

Você também pode criar um arquivo de configuração redocly.yaml para personalizar a geração:

apis:
  main:
    root: openapi.json
theme:
  colors:
    primary:
      main: '#32329f'
  typography:
    fontSize: '14px'

E então usar:

redocly build-docs openapi.json --config redocly.yaml

🔒 Próximos Passos e Melhorias

Para tornar esta API pronta para produção, considere:

Persistência de Dados: Substituir o dicionário em memória por um banco de dados (Entity Framework Core, Dapper, etc.)
Autenticação e Autorização: Implementar JWT, OAuth 2.0 ou Identity
Logging: Adicionar logging estruturado (Serilog, NLog)
Tratamento de Erros Global: Middleware para tratamento centralizado de exceções
Rate Limiting: Limitar requisições por IP/usuário
Caching: Implementar cache para consultas frequentes
Versionamento de API: Suporte para múltiplas versões da API
Testes Automatizados: Unit tests e integration tests
CI/CD: Pipeline de build e deploy automatizado
Monitoramento: Application Insights, Prometheus, etc.

📖 Conclusão

Este projeto demonstra como criar uma API RESTful completa e moderna usando .NET 8 com Minimal APIs. Através do uso de OpenAPI e Redoc, conseguimos gerar documentação automática e interativa, facilitando o desenvolvimento e a integração com outros sistemas.

As Minimal APIs do .NET 8 oferecem uma abordagem simplificada e performática para criar APIs REST, enquanto o OpenAPI e Redoc garantem uma experiência de documentação profissional e acessível.

🤝 Conecte-se Comigo

Se você trabalha com .NET moderno e quer dominar arquitetura, C#, DevOps ou interoperabilidade, vamos conversar:

💼 LinkedIn

💻 DEV Community

✍️ Medium

📰 Substack

📧 Email

⁷ Agora, pois, seja o temor do Senhor convosco; guardai-o, e fazei-o; porque não há no Senhor nosso Deus iniquidade nem acepção de pessoas, nem aceitação de suborno. 2 Crônicas 19:7

🛠️ Do `.SLN` para `.SLNX` no .NET: O que Mudou e Por quê

Danilo O. Pinheiro, dopme.io — Wed, 07 Jan 2026 21:46:20 +0000

O Visual Studio e o ecossistema .NET utilizam há anos arquivos de solução (.sln) para agrupar e organizar projetos dentro de uma solução maior. Porém, com a chegada do .NET 10 e evoluções recentes do SDK e do CLI, um novo formato chamado .slnx está sendo adotado como alternativa mais moderna, legível e sustentável nos fluxos de desenvolvimento.

📌 1. O Problema com `.sln`

O formato tradicional de arquivo .sln existe há décadas e foi projetado quando a Visual Studio era o centro do desenvolvimento Windows. Ele possui diversas características que hoje se tornaram limitantes:

📄 Formato de texto plano com muitos GUIDs, seções e metadados redundantes.
🔀 Merge conflicts frequentes em sistemas de controle de versão (como Git).
✍️ Difícil de editar ou entender manualmente sem experiência.
🧠 Pouca compatibilidade com ferramentas automatizadas.

Esse formato “cresceu orgânico” com o tempo, acumulando configurações duplicadas e ruído, o que dificulta sua manutenção — principalmente em projetos grandes ou desenvolvidos por muitas pessoas.

✨ 2. Por que o `.slnx`?

Visando simplificar, modernizar e facilitar o trabalho em equipe, a Microsoft introduziu um novo formato de solução chamado .slnx.

Principais Motivações:

🧾 Menos verbosidade: arquivo mais curto e fácil de ler.
🛠️ Formato XML: padrão universal, compatível com ferramentas automatizadas.
🔧 Menos conflitos em Git: estrutura mais estável reduz diffs problemáticos.
📊 Ferramentas de build integradas: MSBuild e .NET CLI já suportam .slnx.
🧑‍💻 Melhor manutenção: é mais simples combinar com scripts e automações.

🆕 3. O que mudou no formato

🗂 Estrutura

A diferença é clara quando comparamos:

Antes — .sln:

// Formato antigo com GUIDs e várias seções
Microsoft Visual Studio Solution File, Format Version 12.00
Global
    GlobalSection(SolutionConfigurationPlatforms) = preSolution
        Debug|Any CPU = Debug|Any CPU
        Release|Any CPU = Release|Any CPU
    EndGlobalSection
EndGlobal

Agora — .slnx:

<Solution>
    <Project Path="WebApi/WebApi.csproj" />
    <Project Path="Domain/Domain.csproj" />
</Solution>

O novo formato usa XML simples e direto, sem GUIDs, seções longas ou metadados desnecessários — deixando claro quais projetos pertencem à solução.

🚀 4. Quando isso começou?

O suporte ao .slnx foi introduzido inicialmente como preview no SDK do .NET a partir da versão 9.0.200, com suporte gradativo em CLI e ferramentas como MSBuild.

Com o lançamento do .NET 10, o comando padrão usado por:

dotnet new sln

passou a gerar por padrão arquivos .slnx em vez de .sln.

🛠️ 5. Como funciona no dia a dia

🆕 Criando uma solução com `.slnx`

Ao rodar:

dotnet new sln

Você obterá um arquivo .slnx por padrão, com estrutura XML simples.

🧠 Migrando de `.sln` para `.slnx`

Você pode migrar uma solução antiga usando:

dotnet sln migrate

ou, em Visual Studio (quando a opção estiver habilitada), salvar o arquivo em novo formato.

🧰 Opções da CLI

Se você ainda deseja gerar o formato clássico .sln, pode fazer:

dotnet new sln --format sln

— útil ao manter compatibilidade com ferramentas antigas ou fluxos de trabalho específicos.

🧩 6. Ferramentas e compatibilidade

🧑‍💻 Visual Studio

O suporte ao .slnx já está presente, mas em algumas versões é necessário ativar a opção nas configurações de Preview Features para garantir que o Visual Studio entenda o novo formato.

🎯 MSBuild

O MSBuild suporta totalmente arquivos .slnx, permitindo builds, testes e operações usuais sem impactos significativos.

🌐 CLI e ferramentas de terceiros

O dotnet sln agora pode listar e modificar projetos em .slnx, além de migrar soluções antigas.

Há também bibliotecas como Microsoft.VisualStudio.SolutionPersistence para manipular .slnx programaticamente — útil em scripts ou ferramentas de automação.

📚 7. Principais Benefícios do `.slnx`

🧠 Human-readable: Mais fácil de ler e editar manualmente.
🔄 Menos conflitos no Git: Comentários redundantes e GUIDs eram armadilhas para merge.
⚙ Ferramentas harmonizadas: MSBuild, CLI e IDEs conseguem trabalhar melhor com formato estruturado.
🛠 Automação facilitada: Scripts e ferramentas podem gerar e modificar soluções com mais segurança.

⚠️ 8. Pontos de Atenção

✔️ As equipes devem evitar manter ambos .sln e .slnx no mesmo repositório para evitar confusão e conflitos de ferramentas.
✔️ Algumas IDEs ou extensões antigas podem ainda não ter suporte completo ao novo formato, exigindo atualizações.
✔️ Em casos específicos (Unity/VS Code), pode ser necessário garantir que a versão do SDK suporte .slnx.

📈 Conclusão

O novo formato .slnx representa uma evolução importante no fluxo de desenvolvimento .NET — tornando os arquivos de solução mais simples, legíveis e amigáveis para times modernos e pipelines de CI/CD.

Embora o formato .sln ainda seja amplamente compatível, o .slnx já é o padrão a partir do .NET 10, simplificando o gerenciamento de projetos e reduzindo tópicos recorrentes como conflitos no Git e dificuldade de edição.

🤝 Conecte-se Comigo

Se você trabalha com .NET moderno e quer dominar arquitetura, C#, DevOps ou interoperabilidade, vamos conversar:

💼 LinkedIn
💻 Dev.to
✍️ Medium
📬 daniloopinheiro

¹⁴ E disse ele: Não, mas venho agora como príncipe do exército do Senhor. Então Josué se prostrou com o seu rosto em terra e o adorou, e disse-lhe: Que diz meu Senhor ao seu servo? Josué 5:14

🧾 Console.Write(): Explorando todas as possibilidades!

Danilo O. Pinheiro, dopme.io — Fri, 26 Dec 2025 20:33:33 +0000

Do C# 1.0 ao C# 13

Diferente do Console.WriteLine(), o método Console.Write() não quebra a linha após a escrita.
Ele é muito usado para saídas contínuas, progresso em tempo real, logs formatados e interfaces de console interativas.

🧱 C# 1.0 (2002) – Forma Clássica

using System;

namespace ConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("Hello ");
            Console.Write("World ");
            Console.Write("C# 1.0");
        }
    }
}

📌 Saída:

Hello World C# 1.0

🧩 C# 2.0 (2005)

Sem mudanças diretas na API do Console, mas o padrão permanece:

Console.Write("Hello World - C# 2.0");

🧠 C# 3.0 (2007) – `var`

var text = "Hello World - C# 3.0";
Console.Write(text);

🧠 Código mais limpo com inferência de tipo.

🔄 C# 4.0 (2010) – `dynamic`

dynamic message = "Hello World - C# 4.0";
Console.Write(message);

⚠️ Uso possível, mas não recomendado para cenários simples.

⚡ C# 5.0 (2012) – Assíncrono (Simulação)

using System.Threading.Tasks;

static async Task Main()
{
    Console.Write("Loading");
    await Task.Delay(500);
    Console.Write(".");
    await Task.Delay(500);
    Console.Write(".");
    await Task.Delay(500);
    Console.Write(".");
}

📌 Saída:

Loading...

✨ C# 6.0 (2015) – Interpolação de Strings

var version = "C# 6.0";
Console.Write($"Hello World - {version}");

🧩 C# 7.x (2017–2018) – Tuplas

var info = (Name: "C#", Version: "7.x");
Console.Write($"{info.Name} {info.Version}");

🔐 C# 8.0 (2019) – Nullable Reference Types

string? message = "Hello World - C# 8.0";
Console.Write(message ?? "Mensagem padrão");

🛡️ Proteção contra NullReferenceException.

🧱 C# 9.0 (2020) – Top-Level Statements

Console.Write("Hello World - C# 9.0");

🔥 Código direto, sem Program.cs.

📦 C# 10.0 (2021) – Global Usings

Console.Write("Hello World - C# 10.0");

📉 Menos boilerplate.

🧬 C# 11.0 (2022) – Raw String Literals

Console.Write("""
Hello World - C# 11.0
Sem quebra automática de linha
""");

🧠 C# 12.0 (2023) – Collection Expressions

var parts = ["Hello", "World", "C# 12.0"];
foreach (var part in parts)
{
    Console.Write(part + " ");
}

📌 Saída:

Hello World C# 12.0

🚀 C# 13.0 (Preview / 2025)

Console.Write("Hello World - C# 13.0 (Preview)");

🔮 Evolução focada em imutabilidade e padrões.

🔍 Console.Write vs Console.WriteLine

Método	Comportamento
`Console.Write()`	Continua na mesma linha
`Console.WriteLine()`	Quebra linha automaticamente

🛠️ Casos de Uso Comuns do `Console.Write()`

✔️ Barras de progresso
✔️ Logs contínuos
✔️ CLI interativas
✔️ Animações simples no terminal

Exemplo de progresso:

for (int i = 0; i <= 100; i += 10)
{
    Console.Write($"\rProgresso: {i}%");
    Thread.Sleep(200);
}

✅ Conclusão

Mesmo sendo simples, o Console.Write() acompanhou toda a evolução do C#.
A diferença está na forma como escrevemos código hoje — mais limpo, expressivo e seguro — não no método em si.

Dominar esses detalhes é essencial para escrever ferramentas CLI modernas, scripts, workers e ferramentas DevOps em .NET.

🤝 Conecte-se Comigo

Se você trabalha com .NET moderno e quer dominar arquitetura, C#, DevOps ou interoperabilidade, vamos conversar:

💼 LinkedIn
✍️ Medium
📬 daniloopinheiro

Porque a minha mão fez todas estas coisas, e assim todas elas foram feitas, diz o Senhor; mas para esse olharei, para o pobre e abatido de espírito, e que treme da minha palavra.
Isaías 66:2

🛠️ O que chegou de novo no Visual Studio 2026 Insiders

Danilo O. Pinheiro, dopme.io — Thu, 30 Oct 2025 19:10:32 +0000

📝 Introdução

A Microsoft lançou recentemente o Visual Studio 2026 na versão Insiders, uma prévia que inaugura o que será o futuro da IDE para desenvolvedores em .NET, C#, C++ e workloads que envolvem nuvem, IA e grandes soluções corporativas. ([Microsoft for Developers][1])
Neste artigo, vamos explorar os principais destaques, mostrar como a experiência foi evoluída e o que isso significa para quem desenvolve em .NET moderno.

🚀 Novos Destaques Principais

🤖 Integração profunda com IA

A integração do GitHub Copilot foi ampliada na IDE para ações como Adaptive Paste, onde o código colado é adaptado automaticamente ao contexto do arquivo. ([Microsoft Learn][2])
A pesquisa “Você quis dizer?” (“Did you mean?”) foi adicionada para melhorar a busca dentro do IDE com sugestões baseadas em IA. ([Microsoft Learn][2])
Um agente de profiler com suporte de IA pode sugerir melhorias de desempenho e alocação de memória. ([Visual Studio Magazine][3])

⚡ Performance e produtividade

O VS2026 Insiders promete solução de carregamento e ciclos de build/debug até 30 % mais rápidos em comparação com versões anteriores. ([Microsoft Learn][2])
Suporte otimizado para hardware moderno, tanto em x64 quanto em ARM64. ([c-sharpcorner.com][4])

🎨 Interface modernizada

Nova interface baseada em “Fluent UI”, com maior clareza, novos ícones, melhorias de acessibilidade e 11 novos temas para personalização. ([Visual Studio Magazine][3])
Instalação lado-a-lado com versões anteriores (ex: VS2022), com compatibilidade de extensões e importação de configurações. ([Visual Studio][5])

📚 Suporte a linguagens e plataformas

Suporte completo para .NET 10 e C# 14: novos recursos de linguagem, compilador atualizado, melhor IntelliSense. ([Visual Studio Magazine][3])
Suporte avançado para projetos C++ e workloads de jogo, nuvem, IA. ([Visual Studio][5])

📋 Principais Melhorias Organizacionais

O canal “Insiders” substitui o antigo “Preview” para acesso antecipado a novas funcionalidades. ([Microsoft for Developers][1])
Compatibilidade de extensões: as extensões feitas para VS2022 funcionam no VS2026 Insiders desde o primeiro dia. ([Visual Studio][5])
Ferramentas de cobertura de código disponíveis também para edições Community e Professional – antes restritas a versões Enterprise. ([Microsoft Learn][2])

🧠 Impacto para Desenvolvedores .NET

Para quem trabalha com .NET moderno, essa atualização traz vantagens práticas:

Ao usar .NET 10 e C# 14, você já estará na vanguarda, o que pode evitar “lock-in” em versões antigas.
A integração de IA acelera tarefas repetitivas (refatoração, comentários, adaptação de código) e permite focar em lógica de negócios.
Melhor desempenho da IDE significa mais tempo codificando, menos tempo esperando builds ou debugging.
A customização visual e de experiência ajuda a manter foco e reduzir fadiga em ambientes de longo trabalho.

✅ Conclusão

O Visual Studio 2026 Insiders representa mais do que uma simples atualização: é um passo estratégico rumo às ferramentas de desenvolvimento que combinam IA, performance e design moderno. Embora ainda seja uma versão prévia (Insiders), vale para experimentação.
Se você desenvolve em .NET, vale testar, avaliar a compatibilidade com seus projetos e começar a se preparar para a migração.

🤝 Conecte-se Comigo

Se você trabalha com .NET moderno e quer dominar arquitetura, C#, DevOps ou interoperabilidade, vamos conversar:

💼 LinkedIn
✍️ Medium
📬 dopme.io
📬 devsfree

⁵ Porque na morte não há lembrança de ti; no sepulcro quem te louvará? Salmos 6:5