React é um framework full stack (ou está se tornando um)

xguru · 2024-08-26T10:21:02+09:00

O React, com a adição de Server Components e Server Actions, está evoluindo para um framework full stack O início da guerra dos frameworks em 2010 A guerra dos frameworks, iniciada em 2010 com Backbone, Knockout e Ember, foi rapidamente seguida por Angular e React, e ninguém conseguia prever o resultado Por muito tempo, aplicações JavaScript com renderização no lado do cliente (CSR) dominaram Essas aplicações também são conhecidas como aplicações de página única (SPA) e geralmente eram compostas por um pequeno arquivo HTML e um grande arquivo JavaScript Isso foi assim até a introdução do code splitting Separação entre frontend e backend Durante esse período, o desenvolvimento frontend foi dominado por vários frameworks e bibliotecas JavaScript O backend em geral não ficava preso a uma linguagem específica, e o REST se tornou o padrão de comunicação entre APIs Como desenvolvedor web freelancer, trabalhei principalmente com backends em .NET, Java, Python e PHP Eu só via TypeScript/JavaScript no backend em projetos greenfield ou em projetos pequenos nos quais era possível controlar o backend Mas isso pode mudar com a ascensão do React full stack É interessante como a percepção dos desenvolvedores sobre o período entre 2010 e 2020 varia conforme o momento em que começaram a carreira Desenvolvedores que começaram antes de 2010 viviam em um ambiente de renderização no lado do servidor (SSR) e parecem mais confortáveis com esse retorno recente às tecnologias server-side Já muitos outros passaram quase uma década trabalhando apenas com aplicações de renderização no lado do cliente (CSR) e APIs REST Agora eles não sabem muito bem como encarar esse novo mundo do React full stack TypeScript surge como padrão da indústria Nos últimos anos, o TypeScript surgiu como padrão da indústria O TypeScript oferece aos desenvolvedores frontend uma linguagem de programação tipada e robusta À medida que os desenvolvedores adotaram o TypeScript, chegou-se a um ponto sem volta É interessante como uma pequena mudança no código pode ter um grande impacto em indivíduos e em toda a indústria As dificuldades entre TypeScript e REST O impacto do TypeScript sobre o REST trouxe muitas soluções improvisadas O OpenAPI (antigo Swagger) existia para documentação de APIs REST, mas hoje é usado principalmente para gerar interfaces de tipos para APIs Apesar de ser possível criar interfaces de tipos perfeitas em uma arquitetura cliente-servidor, muitos projetos falham em implementar isso corretamente desde o início Nota pessoal: "Talvez alguns desenvolvedores tenham tido uma boa experiência com arquiteturas baseadas em OpenAPI, mas infelizmente esse não foi o meu caso" TypeScript muda o clima É bem interessante ver como o TypeScript mudou o clima aqui Por um lado, SPAs não tipadas usando REST (com OpenAPI para fins de documentação) pareciam “boas o suficiente” Mas, à medida que o TypeScript se tornou o padrão e passou a ser visto como norma, as interfaces de tipos geradas ficaram desagradáveis de lidar, porque os codebases de frontend passaram a se acostumar com um padrão mais alto As desvantagens das interfaces de tipos geradas são claras: sempre existe uma etapa de geração a saída gerada é complexa dependendo da configuração inicial, o código gerado nem sempre está correto O surgimento de RPC e tRPC RPC não é um conceito novo, mas ganhou popularidade no ecossistema React graças ao tRPC Pela minha experiência de seis meses como desenvolvedor solo em uma aplicação com 80 mil linhas de código, chamar funções no backend para ler e gravar dados foi quase uma revelação Nunca me senti tão produtivo dos dois lados da stack usando TypeScript Pessoalmente, só me senti de forma parecida anos atrás em uma arquitetura GraphQL tipada (gerada) Ao longo de 2023, eu não conseguia imaginar nada melhor do que tRPC Chamar funções no backend para ler e gravar dados parecia revolucionário Mas era só isso de que eu precisava? Não A inovação de Server Components e Server Actions Para mim, o verdadeiro avanço veio em 2024 com Server Components e Server Actions Eles não apenas chamam o servidor, mas também diminuem a distância com ele ao permitir implementar e executar código do outro lado Server Components permitem executar componentes React no servidor, dando acesso direto a fontes de dados (como bancos de dados) antes de retornar a UI em JSX Server Actions podem ser chamadas para executar funções, assim como em chamadas de procedimento remoto, gerando endpoints de API HTTP por baixo dos panos Server Components e Server Actions transformam o React em um framework full stack É um momento empolgante de transformação do frontend em um ambiente full stack Suporte do React a Server Components e Server Actions O próprio React fornece apenas os blocos básicos e a especificação para Server Components e Server Actions Meta-frameworks construídos sobre o React podem preencher essa lacuna com bundlers que interpretam diretivas entre cliente e servidor O Next.js está liderando a implementação de Server Components e Server Actions O Next.js já oferecia suporte a renderização no lado do servidor (SSR), mas agora, com Server Components e Server Actions, os desenvolvedores podem acessar recursos server-side como bancos de dados e filas de mensagens O começo do desenvolvimento full stack O desenvolvimento full stack com React está apenas começando À medida que os desenvolvedores começam a acessar bancos de dados diretamente por meio de Server Components e Server Actions, haverá um processo de domar complexidades que vão além de aplicações CRUD simples Com treinamento sólido, os desenvolvedores frontend logo dominarão a implementação de arquiteturas de backend usando camadas, padrões de projeto e boas práticas Para ser sincero, ninguém quer ver chamadas de funções de ORM dentro de componentes React Expectativa sobre a mudança de paradigma Estou muito empolgado com essa mudança de paradigma Que os desenvolvedores React se preparem para uma nova era em que implementam funcionalidades verticais, da UI até o banco de dados

(robinwieruch.de)

15 pontos por xguru 2024-08-26 | 8 comentários | Compartilhar no WhatsApp

O React, com a adição de Server Components e Server Actions, está evoluindo para um framework full stack

O início da guerra dos frameworks em 2010

A guerra dos frameworks, iniciada em 2010 com Backbone, Knockout e Ember, foi rapidamente seguida por Angular e React, e ninguém conseguia prever o resultado
Por muito tempo, aplicações JavaScript com renderização no lado do cliente (CSR) dominaram
Essas aplicações também são conhecidas como aplicações de página única (SPA) e geralmente eram compostas por um pequeno arquivo HTML e um grande arquivo JavaScript
Isso foi assim até a introdução do code splitting

Separação entre frontend e backend

Durante esse período, o desenvolvimento frontend foi dominado por vários frameworks e bibliotecas JavaScript
O backend em geral não ficava preso a uma linguagem específica, e o REST se tornou o padrão de comunicação entre APIs
Como desenvolvedor web freelancer, trabalhei principalmente com backends em .NET, Java, Python e PHP
Eu só via TypeScript/JavaScript no backend em projetos greenfield ou em projetos pequenos nos quais era possível controlar o backend
Mas isso pode mudar com a ascensão do React full stack
É interessante como a percepção dos desenvolvedores sobre o período entre 2010 e 2020 varia conforme o momento em que começaram a carreira
Desenvolvedores que começaram antes de 2010 viviam em um ambiente de renderização no lado do servidor (SSR) e parecem mais confortáveis com esse retorno recente às tecnologias server-side
Já muitos outros passaram quase uma década trabalhando apenas com aplicações de renderização no lado do cliente (CSR) e APIs REST
Agora eles não sabem muito bem como encarar esse novo mundo do React full stack

TypeScript surge como padrão da indústria

Nos últimos anos, o TypeScript surgiu como padrão da indústria
O TypeScript oferece aos desenvolvedores frontend uma linguagem de programação tipada e robusta
À medida que os desenvolvedores adotaram o TypeScript, chegou-se a um ponto sem volta
É interessante como uma pequena mudança no código pode ter um grande impacto em indivíduos e em toda a indústria

As dificuldades entre TypeScript e REST

O impacto do TypeScript sobre o REST trouxe muitas soluções improvisadas
O OpenAPI (antigo Swagger) existia para documentação de APIs REST, mas hoje é usado principalmente para gerar interfaces de tipos para APIs
Apesar de ser possível criar interfaces de tipos perfeitas em uma arquitetura cliente-servidor, muitos projetos falham em implementar isso corretamente desde o início
Nota pessoal: "Talvez alguns desenvolvedores tenham tido uma boa experiência com arquiteturas baseadas em OpenAPI, mas infelizmente esse não foi o meu caso"

TypeScript muda o clima

É bem interessante ver como o TypeScript mudou o clima aqui
Por um lado, SPAs não tipadas usando REST (com OpenAPI para fins de documentação) pareciam “boas o suficiente”
Mas, à medida que o TypeScript se tornou o padrão e passou a ser visto como norma, as interfaces de tipos geradas ficaram desagradáveis de lidar, porque os codebases de frontend passaram a se acostumar com um padrão mais alto
As desvantagens das interfaces de tipos geradas são claras:
- sempre existe uma etapa de geração
- a saída gerada é complexa
- dependendo da configuração inicial, o código gerado nem sempre está correto

O surgimento de RPC e tRPC

RPC não é um conceito novo, mas ganhou popularidade no ecossistema React graças ao tRPC
Pela minha experiência de seis meses como desenvolvedor solo em uma aplicação com 80 mil linhas de código, chamar funções no backend para ler e gravar dados foi quase uma revelação
Nunca me senti tão produtivo dos dois lados da stack usando TypeScript
Pessoalmente, só me senti de forma parecida anos atrás em uma arquitetura GraphQL tipada (gerada)
Ao longo de 2023, eu não conseguia imaginar nada melhor do que tRPC
Chamar funções no backend para ler e gravar dados parecia revolucionário
Mas era só isso de que eu precisava? Não

A inovação de Server Components e Server Actions

Para mim, o verdadeiro avanço veio em 2024 com Server Components e Server Actions
Eles não apenas chamam o servidor, mas também diminuem a distância com ele ao permitir implementar e executar código do outro lado
Server Components permitem executar componentes React no servidor, dando acesso direto a fontes de dados (como bancos de dados) antes de retornar a UI em JSX
Server Actions podem ser chamadas para executar funções, assim como em chamadas de procedimento remoto, gerando endpoints de API HTTP por baixo dos panos
Server Components e Server Actions transformam o React em um framework full stack
É um momento empolgante de transformação do frontend em um ambiente full stack

Suporte do React a Server Components e Server Actions

O próprio React fornece apenas os blocos básicos e a especificação para Server Components e Server Actions
Meta-frameworks construídos sobre o React podem preencher essa lacuna com bundlers que interpretam diretivas entre cliente e servidor
O Next.js está liderando a implementação de Server Components e Server Actions
O Next.js já oferecia suporte a renderização no lado do servidor (SSR), mas agora, com Server Components e Server Actions, os desenvolvedores podem acessar recursos server-side como bancos de dados e filas de mensagens

O começo do desenvolvimento full stack

O desenvolvimento full stack com React está apenas começando
À medida que os desenvolvedores começam a acessar bancos de dados diretamente por meio de Server Components e Server Actions, haverá um processo de domar complexidades que vão além de aplicações CRUD simples
Com treinamento sólido, os desenvolvedores frontend logo dominarão a implementação de arquiteturas de backend usando camadas, padrões de projeto e boas práticas
Para ser sincero, ninguém quer ver chamadas de funções de ORM dentro de componentes React

Expectativa sobre a mudança de paradigma

Estou muito empolgado com essa mudança de paradigma
Que os desenvolvedores React se preparem para uma nova era em que implementam funcionalidades verticais, da UI até o banco de dados

8 comentários

t7vonn 2024-09-02

Já fez tudo do full stack, né

wan2land 2024-08-26

Se você considerar compatibilidade com outras linguagens, como no desenvolvimento de apps, acho que o tRPC não é uma escolha tão boa assim. 😅
Eu acho que GraphQL é a melhor opção.

click 2024-08-26

A server action do Next.js tem o problema de expor publicamente endpoints de API aleatórios que o desenvolvedor não consegue controlar, e acho que isso é uma parte extremamente vulnerável.

2024-08-27

[Este comentário foi ocultado.]

pasg0725 2024-08-26

Você poderia dizer a qual vulnerabilidade estava se referindo? Quando pesquiso, aparece uma vulnerabilidade de SSRF, mas não tenho certeza se é essa. Estou estudando Next.js agora e fiquei curioso, então resolvi perguntar.

savvykang 2024-08-26

Qual era, afinal, a intenção de quem promovia SPA desde o começo? É muito melhor do que na época em que se manipulava o DOM com jquery, mas parece que os conceitos necessários para arquitetura e desenvolvimento de backend e frontend não desaparecem, só mudam de lugar. Só de pensar em roteamento, ele foi do servidor para o cliente e agora, por causa da popularidade da renderização no lado do servidor, estão tentando levá-lo de volta para o servidor.

Também fico em dúvida se, daqui a 3 anos, cursos e bootcamps de programação ainda vão ensinar React no estilo SPA.

superwoou 2024-08-28

A maior vantagem não era justamente a suavidade na navegação entre páginas? (naquela época)

xguru 2024-08-26

O final do texto original termina com a divulgação do curso de desenvolvimento web full stack The Road to Next, que o autor pretende lançar em breve ^^;