Eu acho que o "defender o fim do padrão SPA + REST?" é um exagero gritante.

Nossa área tende a ser alvejada constantemente com balas de prata, panaceias que solucionam tudo, o que é curioso, porque profissionais que teoricamente trabalham com lógica, deveriam ser menos propensos a isso, pelo menos na media.

Pra mim o maior sinal de um profissional maduro (e por extensão de uma equipe madura) é reconhecer as Ferramentas certas, não só para o que se está tentando solucionar, mas para o time e para o mercado, e com o avanço de ferramentas de IA Generativas isso vai ficar ainda mais necessário.

Vou te contar uma historia real, que pode ser anedotica, mas geralmente a experiencia é:

Eu conheci um rapaz que tinha começado uma startup que era baseada num app, ele tinha contatos no ramo, uma boa validação de mercado e de concorrentes.

Pra fazer o app ele contratou um colega que amava flutter pra desenvolver, o rapaz tinha aprendido flutter e flutter era a melhor coisa do mundo, React Native era horrível, Expo ia destruir a ideia, Nativo era inútil...Era flutter no céu e o google na terra.

Ele fez o app, o app ta rodando, muito bem por sinal e esse colega conseguiu um emprego alocado em outro estado e foi embora.

Dai começou a jornada do dono da startup, primeiro ele descobriu que precisava do código fonte, que não tinha sido entregue, depois disso ele tinha que achar algum dev flutter... ele ficou meses até finalmente fechar com uma empresa em outro estado para dar manutenção. Tempo que os concorrente usaram para melhorar o produto, tempo que ele perdeu oportunidades e dinheiro numa fase vital do negócio dele.

Flutter é ruim? nem de longe. Só era a tecnologia errada, na hora errada.

Oi @GheistLycis,

Eu sou o interlocutor mencionado no artigo e, por conta disso, acho importante esclarecer alguns pontos que podem gerar mal-entendidos.

Antes de tudo, é importante separar conceitos diferentes para não colocar todas as controvérsias no mesmo balaio.

Um conceito fundamental é o REST. REST é um estilo arquitetural descrito na dissertação de Roy Fielding, um dos autores das RFCs que definiram o protocolo HTTP — parte essencial do que chamamos de Web.

Quando ele escreveu essa dissertação (e as primeiras RFCs da Web), JSON ainda não existia. Mas o HTML já existia, assim como todo o conjunto de ideias que compõem os sistemas hipermídia (hypermedia): documentos com diferentes representações interligados por meio de URLs.

Os clientes que acessavam esses sistemas — chamados de User Agents — eram, principalmente, os navegadores (browsers).

Nesse ponto da história, a Web já funcionava perfeitamente com sua arquitetura REST (embora o termo ainda não tivesse sido cunhado), com servidores e clientes se comunicando sem necessidade de JavaScript ou JSON (que sequer existia).

Com o tempo, a Web evoluiu de um sistema hipermídia para uma plataforma de aplicações. Essa evolução foi rápida — mais rápida do que os servidores e navegadores conseguiam acompanhar.

Essas limitações impediam o desenvolvimento de certos tipos de aplicação, até que o Google implementou um “hack” usando uma extensão peculiar do JavaScript chamada XMLHttpRequest para seu cliente de e-mail, o Gmail. Assim nasceu uma revolução no desenvolvimento Web. Vale notar: o nome do objeto é XML — não JSON.

Esse recurso, junto com o surgimento da excelente engine V8, possibilitou uma Web muito mais dinâmica, onde aplicações com interfaces complexas — como Onshape, Figma, Miro e Google Docs — passaram a ser inteiramente implementadas em JavaScript, no cliente, com altíssima responsividade.

Foi aí que surgiram as primeiras SPAs (Single-Page Applications). Pareciam uma ideia genial! Finalmente, desenvolver para a Web se parecia com desenvolver para desktop. O backend poderia ser apenas uma interface para o armazenamento, enquanto tudo rodava no cliente. E o JSON nascia como um formato leve para transportar dados, sem se preocupar com semântica.

Com o Node.js, então, bastava aprender uma linguagem: JavaScript.

O problema começou quando essa abordagem se tornou a única forma possível de se desenvolver para a Web.

Se é verdade que, para fazer um Miro, Figma ou Google Sheets, rodar tudo no cliente é vantajoso (se não a única opção) — quais são as vantagens dessa abordagem para uma aplicação corporativa que, na prática, é apenas um CRUD um pouco mais sofisticado?

Evitar recarregar a página inteira ao clicar em “Salvar” porque isso seria “lento”? Honestamente, quantas vezes você viu um spinner girando na tela enquanto a API demora para responder? De que adianta reimplementar em JavaScript algo que qualquer navegador moderno já faz “de fábrica” — renderizar um HTML pronto — se o tempo total para receber e processar um JSON (deserializar, injetar no DOM, renderizar via JS) é o mesmo?

Sim, o ecossistema de JS (e TS) evoluiu muito. Mas os navegadores também evoluíram — e os protocolos idem (já leu sobre HTTP/3 e QUIC e suas capacidades de comunicação assíncrona e paralela?).

Se usarmos a Web como ela foi concebida — com navegadores e servidores modernos, boa arquitetura (cache, CDNs, workers, microfronts etc.) — é bem provável que o seu projeto precise de muito menos JavaScript do que você imagina.

É claro que não estou dizendo que dá para desenvolver tudo na Web sem JS (embora esse seja meu sonho). JavaScript é — e continuará sendo — necessário em vários pontos. A questão é: precisamos usar JS para tudo? Precisamos reimplementar, em JS, coisas que o navegador já faz?

Deixo um desafio: tente desenhar suas aplicações Web sempre se perguntando:

“Como eu faria isso funcionar em um navegador com o JavaScript completamente desabilitado?”

A discussão sobre monólito vs. microserviços, mencionada pelo @GheistLycis, é independente dessa aqui — e grande demais para caber neste comentário. Posso falar sobre isso depois: já tive sucesso com um projeto em microserviços, e no projeto atual estou fazendo o caminho inverso (microserviços → monólito). Cada caso pede uma arquitetura diferente. O importante é refletir profundamente sobre o problema antes de decidir.

Por fim, gostaria de dizer que alguns comentários deste post refletem muito bem o que tentei explicar (por exemplo, o do @thiagoandre).

Aos que pedem exemplos práticos: eles ainda são poucos, porque essa discussão — que propõe um “retorno às origens” — é relativamente recente (surgiu por volta da pandemia) e nasceu de forma “tumultuada”, muito por causa do tom irreverente da turma do HTMX, principal proponente dessa abordagem.

Para quem quiser se aprofundar, seguem algumas referências:

• Fielding’s Dissertation — dissertação que introduz o conceito de REST.
• Hypermedia Systems — livro gratuito dos criadores do HTMX, que fundamenta vários conceitos abordados aqui (como HATEOAS).
• A Web é uma API — slides da minha palestra sobre a ideia de criar APIs que também funcionem como aplicações Web. Faz par com meu projeto Toy, que apresentarei como tutorial na Python Brasil 2025 em outubro. Há também o vídeo dessa palestra.

Esse texto foi revisado e as ênfases foram dadas pelo ChatGPT.

Meu irmão que artigo ! Vim pela curiosidade por que gosto dessas discussões e sempre aprendo algo mas achei bem sensato e na verdade penso que é bem isso. NÃO EXISTE A MELHOR E UNICA SUFICIENTE SOLUÇÃO! A solução depende do cenário, do contexto, do orçamento disponível e principalmente do problema a ser resolvido, e essa é a beleza da coisa. Com quase 20 anos de carreira (o que nao é muita coisa) a única certeza que eu tenho é que tudo depende rsrsrs pior coisa é ser fanboy de tecnologia ou se obrigar a usar apenas a x ou y, mas penso que o desafio é manter a mente aberta sem perder o foco.

Ainda acho que SSR tradicional faz muito sentido. Aliás, faz mais sentido na maioria dos casos.
Com ele, o desenvolvimento é mais ágil: um repo, um build, um deploy. Menos npm e menos dependência de terceiros = menor superfície de ataque e menos CVEs.
A equipe pode ser menor e mais generalista, o que reduz custo e complexidade.

Em performance, SSR aguenta bem com cache, CDN e otimização de banco.
E se o projeto crescer a ponto de precisar de recursos mais avançados (tempo real, offline, UI pesada), é porque ele já dá retorno financeiro e pode bancar uma equipe mais especializada.

Outro ponto que já sofri inúmeras vezes com SPAs, é a regra de negócio ser espalhada pelo front e no back. Um SSR tradicional pode evita duplicar regras em dois lugares diferentes.

SPA faz mais sentido (para mim) quando há interação tipo editores complexos, colaboração em tempo real, ou uso offline.
Pra maioria dos sistemas, SSR já entrega uma UX muito boa. E convenhamos, 95% dos sistemas desenvolvidos no mundo são de pequeno a médio porte e que foram criado por 4, 3 ou até 1 dev.

E hoje em dia, os frameworks já estão bem maduros e trazendo soluções robustas para sanar os gaps dos SSRs. Trabalho com o Laravel e em conjunto com Livewire, Alpine, Inertia ou HTMX e tá sensacional.

O modelo SPA + REST nasceu em um tempo em que os navegadores eram limitados e o servidor só conseguia renderizar HTML estático. Hoje esse cenário mudou completamente. Continuar separando frontend e backend em dois projetos distintos é insistir em uma complexidade que não traz ganho real. Essa arquitetura cria redundância — dados trafegam via HTTP entre duas camadas que poderiam se comunicar diretamente. Serialização, validações duplicadas e inconsistências de versão viram o dia a dia. No fim, é mais código, mais build, mais deploy e mais chance de erro.

A ideia de que SPAs são mais rápidos também não se sustenta. O carregamento inicial é pesado, o navegador precisa interpretar megabytes de JavaScript, hidratar a página e reconstruir o DOM. Enquanto isso, um SSR moderno entrega HTML pronto e interativo em milissegundos, aproveitando cache, fragmentos e streaming. O usuário vê conteúdo real muito antes — e sem depender de bundles, hydration e loaders intermináveis. A percepção de velocidade, que é o que importa, é muito melhor.

Além disso, SPAs trouxeram problemas que o SSR já tinha resolvido há décadas: estados inconsistentes, race conditions, duplicação de lógica e a necessidade de reinventar o controle de sessão no cliente. Hoje temos tecnologias como HTMX, Viewi, Livewire e Inertia que permitem criar interfaces ricas e interativas sem mover a aplicação inteira para o navegador. O resultado é código mais limpo, menos dependências e manutenção mais simples.

Separar projetos também não é o mesmo que separar responsabilidades. Podemos ter uma arquitetura limpa, modular e testável dentro de um mesmo repositório — com deploy atômico, versionamento coeso e comunicação direta entre camadas. O mito da “separação por stack” só aumenta a fricção entre times e torna cada ajuste um problema de integração.

Em resumo, SPA + REST é uma solução para um problema que a web moderna já resolveu. Não é uma evolução, é um desvio histórico. Hoje faz mais sentido unir as camadas novamente, aproveitando o que cada lado tem de melhor — o servidor cuidando da lógica e o navegador da interação — em um fluxo contínuo e integrado. Isso não é um retrocesso, é um retorno à eficiência.

Acredito que este tipo tipo de visão desconsidera uma infinidade de variáveis.
Quando se trata de um site público, que precisa ser indexado pelo Google, inúmeras métricas são avaliadas. Uma das principais hoje em dia é INP que substituiu o FID como métrica de performance. Isso significa que não basta o site "carregar" rápido, toda a experiência de navegação é considerada. Um site SSR tem um carregamento inicial extremamente rápido, isso é fato, ainda mais quando combinado com cache na borda etc. Porém, é o próximo clique do usuário, como fica? Se a cada interação você tiver que trazer todo o html novamente a experiência de navegação fica muito prejudicada. No final, não se trata apenas de dar ou não dar para fazer mas sim a fluidez de toda a experiência do usuário durante sua sessão. Recentemente com o lançamento do material design 3 Expressive, por exemplo, o Google trouxe testes e benchmarks de como uma simples mudança na no cálculo da animação e das micro interações (trocando o easing tradicional para animação baseada em física) pode reter mais o usuário.
Saindo já do campo "usuário" temos também a especialidade do desenvolvedor. Claro que projeto pequeno um fullstack resolve mas, em projetos grandes, um Front end e um back end totalmente especialistas vão entregar uma qualidade final muito superior do que um generalista.
Achar que SSR resolve problemas de regras de negócio no Front, gerenciamento de estado e tudo mais, também é um erro enorme. No Front você está lidando com o estado e regras da interface e não do negócio. Se está misturando, significa que o sistema foi mal arquitetado. Se está se preocupando com replicar validação do Front e back, significa que não está usando um padrão de open api / json schema robusto que expõe as regras.
Infelizmente, o que mais conheço são programadores "experientes" que falam que tudo isso é frescura, mas que não fazem ideia do que é arquitetar um sistema distribuído e com vários níveis de tolerância a falha, otimizações de performance na casa dos ms, acompanhamento p90, p99 etc.

Vc pode simplementes voltar pra .php e jquery :)

SPA + REST já morreu, só esqueceram de avisar o pessoal.
O modelo atual é o HTML-first, enriquecido com JS, e isso é exatamente o que Nuxt, Next, Astro e companhia já fazem há tempo. SSR e CSR não são mais polos opostos, é tudo híbrido agora.

O ponto que quase ninguém toca: se todo o seu sistema é o "webapp", algo está profundamente errado. O navegador é só a GUI. Qualquer coisa séria envolve backend real, processamento, domínio, persistência, integração. E se você já tem tudo isso do lado do servidor, qual o sentido de serializar tudo em JSON pra re-hidratar no cliente, quando você pode simplesmente mandar o HTML pronto, cacheável, indexável e já otimizado?

A web amadureceu. O retorno ao servidor não é nostalgia, é eficiência. O SPA foi uma resposta ao que os navegadores não conseguiam fazer. Agora eles conseguem. O futuro é simples de novo, e elegante.

Um abraço e bons estudos!

Não sou a favor e nem contra, pois nem da área web eu sou, ahaahaha.

Mas uma coisa q percebi é q se a tecnologia ainda existe, é pq é um desses 3 motivos: projeto legado q está em funcionamento (tipo sistemas em cobol), entusiastas (pessoas q gostam de manter aquela tecnologia) e pq ainda é útil.

Eu gosto do debate extremo para nos trazer prismas. No dia a dia eu tenho preferido trabalhar de forma híbrida.
Os cruds normalmente tenho feito lista e form carregando individualmente e os comportamentos em ajax.
Se é uma tela mais complexa, eu vejo caso a caso. Isso tem muita ligação com o texto que postei aqui esses dias.
Eu, pessoalmente (de novo), não tenho boa experiência com SPAs e, sinceramente, todos os sistemas que integro que são SPAs tem APIs bem problemáticas.
Essa “coisa” de usar a mesma API para a interface do sistema e para API externa só me trouxe dor de cabeça. Sempre que integro com sistema assim, sempre tenho dor de cabeça. Então nunca trabalhei com esse modelo para evitar as dores de cabeça estando do outro lado também.

No final, eu realmente acredito que junto com experiência a gente acumula muito trauma e camadas de proteção, isso acaba refletindo em nossas aplicações como um todo.

Quantas vezes precisou trocar o banco de dados de uma aplicação?
Quantas vezes aquelas duas ou três situações que você enche o código para caso precise, realmente aconteceram?

Eu tenho abdicado de alguns, vários, conceitos e programado orientado aos projetos. Hoje tenho uma estrutura minha onde desenvolvi tudo do zero de forma muito simples. Isso acontece muito comigo, usar aquela library magnífica que tem 5000 funcionalidades que eu não uso, 2 que uso e 3 que o cliente fica frustrado por não ser possível ter.

Criei meus select com filtro, que funciona lindamente no desktop e mobile.

Fiz meu draggable, sortable, diálogo e com eles eu posso extender o que precisar. E não tenho mais trabalho por isso, bem contrário, meu código é limpo e posso estender até onde precisar.

Acha que eu não faço coisas complexas? Faço bastante, mas não preciso tornar meu código um emaranhado de coisas para mostrar valor. A qualidade tá na entrega, na manutenibilidade, no tempo resposta em casos de erro e na confiança dos meus clientes.

Não existe bala de prata, devemos estar abertos a escolher a ferramenta certa para cada problema.

Um texto tão grande para uma solução tão obvia: Ele esta errado!

Eu sou a favor da troca do rest pelo graphql, por inúmeras vantagens, mas tambem discordo que o spa seja lento. Ao contrario, nos permite trabalhar com microfrontend.
.