← Voltar ao blog
2026-02-23

Migrando do Backend para o Fullstack com Next.js: O que muda para um dev C#?

arquiteturanextjscsharpfullstackcarreira

IA-Summary

Este resumo foi gerado para sua conveniência. As análises, decisões e opiniões a seguir são de autoria humana, baseadas em experiência real de transição de um backend .NET para Next.js.

  • A maior mudança para um dev C# não é a linguagem — é a mentalidade estrutural
  • Em Next.js, pastas definem comportamento, não apenas organização
  • Rotas deixam de ser explícitas como no ASP.NET
  • A ausência de DI tradicional gera desconforto inicial
  • Layout vira responsabilidade direta do desenvolvedor
  • Para projetos pequenos, Next pode substituir um backend tradicional
  • A melhor resposta para quem quer migrar: Só vai.

Eram só pastas. Até eu perceber que não eram.

Quando comecei a montar meu portfólio, eu não sabia absolutamente nada de Next.js.

Zero.

Eu vinha de anos estruturando aplicações .NET.
Minha primeira reação foi pensar:

"Frontend é só a camada visual. O backend continua sendo o cérebro."

Eu estava errado.

O primeiro choque veio com algo aparentemente simples: a estrutura de pastas.

No backend, pastas são organização.
No Next, a pasta define comportamento no build.

Ela define:

  • Rota
  • Tipo de renderização
  • Layout
  • Escopo do componente

Não é organizacional. É arquitetural.


Contexto da decisão

Meu objetivo era:

  • Criar um portfólio público
  • Mostrar habilidade fullstack
  • Aprender algo moderno
  • Publicar rápido

Considerei Angular.

Ele é mais estruturado. Mais próximo da mentalidade C#.
Mas o objetivo não era conforto.

Era expansão.

Então escolhi Next.js.


Conflito #1 — Rotas implícitas

No ASP.NET Core:

[HttpGet("api/posts/{id}")]
public async Task<IActionResult> GetPost(Guid id)

Explícito. Tipado. Declarado.

No Next:

/app/blog/[slug]/page.tsx

A rota nasce da pasta.

Para quem vem do C#, isso gera desconforto imediato.


Conflito #2 — Cadê minha DI?

No backend:

builder.Services.AddScoped<IService, Service>();

No Next, você importa dependências diretamente.

Isso me incomodou.

Mas frontend resolve outro tipo de problema.

Nem todo padrão precisa existir em todos os contextos.


Conflito #3 — Layout importa

No backend eu não penso em layout.

No frontend, layout é produto.

O ecossistema de libs no Next é absurdo. Tailwind. Component libraries. Motion.

A velocidade de prototipação é insana.


A decisão estratégica mais importante

Eu publiquei a V1 sem backend.

Apenas:

  • Frontend
  • Dados mockados
  • Deploy no Vercel
  • CI/CD com GitHub Actions

Valor primeiro. Arquitetura depois.


Next substitui .NET?

Para landing pages e projetos pequenos, sim.

Para sistemas complexos, não.

Não é substituição. É contexto.


Se um dev C# me perguntar: devo migrar?

Minha resposta honesta:

Só vai.


FAQ

Next.js é melhor que Angular para devs .NET?

Depende do objetivo.

Next substitui ASP.NET?

Para projetos pequenos, sim.

Vale a pena backend aprender frontend?

Sim.


Sobre o autor

Desenvolvedor .NET com foco crescente em arquitetura, performance e observabilidade.