Componentes de Servidor React: O Futuro do Desenvolvimento em React

React tem sido uma potência para o desenvolvimento de aplicativos web nos últimos dez anos.

Todos nós vimos evoluir daquelas componentes de classe pesadas para a elegância dos hooks.

Mas os Componentes de Servidor React (RSCs)?

Não achamos que alguém esperava uma mudança tão dramática no funcionamento do React.

Então, o que exatamente são Componentes de Servidor React? Como eles funcionam? E o que eles fazem de diferente que o React já não poderia fazer?

Para responder a todas essas perguntas, vamos revisar rapidamente os fundamentos. Se você precisa de uma revisão, dê uma olhada rápida neste guia sobre como aprender React como iniciante.

Neste post, vamos explicar por que precisávamos dos Componentes de Servidor React, como eles funcionam e alguns dos principais benefícios dos RSCs.

Comece Agora!

O que são Componentes de Servidor React?

Pense nos Componentes de Servidor React como uma nova maneira de construir aplicações React. Em vez de executarem no navegador como os componentes React típicos, os RSCs executam diretamente no seu servidor.

“Eu acho que os RSCs são projetados para ser a “componentização” do backend, ou seja, o equivalente no backend do que o SPA React fez pelo frontend. Em teoria, eles poderiam eliminar em grande parte a necessidade de coisas como REST e GraphQL, levando a uma integração muito mais estreita entre o servidor e o cliente, já que um componente poderia atravessar toda a pilha.” — ExternalBison54 no Reddit

Como os RSCs são executados diretamente no servidor, eles podem acessar de maneira eficiente recursos do backend como bancos de dados e APIs sem uma camada adicional de busca de dados.

Mas por que precisávamos dos RSCs afinal?

Para responder a essa pergunta, vamos voltar um pouco.

React Tradicional: Renderização no Lado do Cliente (CSR)

O React sempre foi uma biblioteca de interface de usuário do lado do cliente.

A ideia principal por trás do React é dividir todo o seu design em unidades menores e independentes que chamamos de componentes. Esses componentes podem gerenciar seus próprios dados privados (state) e passar dados uns para os outros (props).

Pense nestes componentes como funções JavaScript que são baixadas e executadas diretamente no navegador do usuário. Quando alguém visita seu aplicativo, o navegador dessa pessoa baixa todo o código do componente, e o React entra em ação para renderizar tudo:

• O navegador baixa o HTML, JavaScript, CSS e outros recursos.
• React analisa o HTML, configura ouvintes de eventos para interações do usuário e recupera quaisquer dados necessários.
• O site se transforma em uma aplicação React totalmente funcional bem diante de seus olhos e tudo é feito pelo seu navegador e computador.

Embora este processo funcione, ele possui algumas desvantagens:

• Tempos de carregamento lentos: Os tempos de carregamento podem ser lentos, particularmente para aplicações complexas com muitos componentes, pois agora o usuário precisa esperar que tudo seja baixado primeiro.
• Ruim para otimização para motores de busca (SEO): O HTML inicial é frequentemente básico — apenas o suficiente para baixar o JavaScript que depois renderiza o restante do código. Isso dificulta a compreensão dos motores de busca sobre o conteúdo da página.
• Fica mais lento conforme os aplicativos crescem: O processamento do lado do cliente do JavaScript pode sobrecarregar os recursos, levando a uma experiência de usuário mais áspera, especialmente à medida que você adiciona mais funcionalidades.

A Próxima Iteração: Renderização no Lado do Servidor (SSR)

Para abordar os problemas causados pela renderização no lado do cliente, a comunidade React adotou a Renderização do Lado do Servidor (SSR).

Com SSR, o servidor lida com a renderização do código para HTML antes de enviá-lo.

Este HTML completo renderizado é então transferido para o seu navegador/celular, pronto para ser visualizado — o aplicativo não precisa ser compilado durante a execução, como seria sem o SSR.

Veja como o SSR funciona:

• O servidor renderiza o HTML inicial para cada solicitação.
• O cliente recebe uma estrutura HTML completamente formada, permitindo carregamentos iniciais de página mais rápidos.
• O cliente então baixa o React e o código da sua aplicação, um processo chamado de “hidratação”, que torna a página interativa.

A estrutura HTML renderizada no servidor ainda não possui funcionalidade. 

React adiciona ouvintes de eventos, configura a gestão de estado interna e adiciona outras funcionalidades ao HTML depois de ser baixado para o seu dispositivo. Esse processo de adicionar “vida” à página é conhecido como hidratação.

Por que o SSR funciona tão bem?

1. Tempos de carregamento inicial mais rápidos: Os usuários veem o conteúdo quase instantaneamente porque o navegador recebe HTML totalmente formado, eliminando o tempo necessário para o carregamento e execução do JavaScript.
2. Melhoria no SEO: Os motores de busca rastreiam e indexam o HTML renderizado pelo servidor facilmente. Este acesso direto se traduz em uma melhor otimização de motores de busca para sua aplicação.
3. Desempenho aprimorado em dispositivos mais lentos: SSR reduz a carga no dispositivo do usuário. O servidor assume o trabalho, tornando sua aplicação mais acessível e eficiente, mesmo em conexões mais lentas.

O SSR, no entanto, causou uma série de problemas adicionais, exigindo uma solução ainda melhor:

• Tempo Lento para Interativo (TTI): A renderização no lado do servidor e a hidratação atrasam a capacidade do usuário de ver e interagir com o aplicativo até que todo o processo esteja completo.
• Carga do servidor: O servidor precisa realizar mais trabalho, atrasando ainda mais os tempos de resposta para aplicações complexas, especialmente quando há muitos usuários simultaneamente.
• Complexidade de Configuração: Configurar e manter pode ser mais complexo, especialmente para aplicações grandes.

Finalmente, os Componentes de Servidor React

Em dezembro de 2020, a equipe do React apresentou os “Componentes de Servidor React de Tamanho Zero de Pacote” ou RSCs.

Isso mudou não apenas como pensávamos em construir aplicativos React, mas também como os aplicativos React funcionam nos bastidores. Os RSCs resolveram muitos problemas que tínhamos com CSR e SSR.

“Com os RSCs, o React se torna um framework totalmente do lado do servidor e também totalmente do lado do cliente, o que nunca tivemos antes. E isso permite uma integração muito mais próxima entre o código do servidor e do cliente do que era possível anteriormente.” — ExternalBison54 no Reddit

Vamos agora analisar os benefícios que os RSCs oferecem:

1. Tamanho do Pacote Zero

Os RSCs são renderizados inteiramente no servidor, eliminando a necessidade de enviar código JavaScript para o cliente. Isso resulta em:

• Tamanhos dramaticamente menores de pacotes JavaScript.
• Carregamentos de página mais rápidos, especialmente em redes mais lentas.
• Desempenho melhorado em dispositivos menos potentes.

Ao contrário do SSR, onde toda a árvore de componentes React é enviada para o cliente para hidratação, os RSCs mantêm o código somente para servidor no servidor. Isso leva a pacotes do lado do cliente significativamente menores, como falamos, tornando suas aplicações mais leves e mais responsivas.

2. Acesso Direto ao Backend

Os RSCs podem interagir diretamente com bases de dados e sistemas de arquivos sem necessidade de uma camada API.

Como você pode ver no código abaixo, a variável cursos é obtida diretamente do banco de dados, e a interface do usuário imprime uma lista do curso.id e curso.nome a partir do cursos.map:

async function CourseList() {
  const db = await connectToDatabase();
  const courses = await db.query('SELECT * FROM courses');

  return (
    <ul>
      {courses.map(course => (
        <li key={course.id}>{course.name}</li>
      ))}
    </ul>
  );
}

Isso é mais simples em contraste com o SSR tradicional, onde você precisaria configurar rotas de API separadas para buscar pedaços individuais de dados.

3. Divisão Automática de Código

Com os RSCs, você também obtém uma divisão de código mais granular e uma melhor organização de código.

React mantém o código apenas do servidor no servidor e garante que ele nunca seja enviado para o cliente. Os componentes do cliente são automaticamente identificados e enviados ao cliente para hidratação.

E o pacote geral torna-se extremamente otimizado, já que o cliente agora recebe exatamente o que é necessário para um aplicativo totalmente funcional.

Por outro lado, o SSR precisa de uma divisão de código manual cuidadosa para otimizar o desempenho para cada página adicional.

4. Efeito de Cascata Reduzido e Renderização por Streaming

Os Componentes de Servidor React combinam a renderização por streaming e a busca de dados em paralelo. Essa combinação poderosa reduz significativamente o “efeito cascata” frequentemente observado na renderização tradicional do lado do servidor.

Efeito Cascata

O “efeito cascata” retarda o desenvolvimento web. Basicamente, ele obriga as operações a se sucederem como se uma cachoeira estivesse fluindo sobre uma série de rochas.

Cada passo deve esperar que o anterior termine. Essa “espera” é especialmente perceptível na busca de dados. Uma chamada de API deve ser concluída antes que a próxima comece, causando uma desaceleração nos tempos de carregamento da página.

Renderização por Streaming

A renderização por streaming oferece uma solução. Em vez de esperar que toda a página seja renderizada no servidor, o servidor pode enviar pedaços da interface do usuário para o cliente assim que estiverem prontos.

Os Componentes de Servidor React tornam a renderização e a busca de dados muito mais suaves. Ele cria múltiplos componentes de servidor que trabalham em paralelo evitando esse efeito cascata.

O servidor começa a enviar HTML para o cliente no momento em que qualquer parte da interface do usuário está pronta.

Então, em comparação com a renderização do lado do servidor, os RSCs:

• Permita que cada componente busque seus dados de forma independente e em paralelo.
• O servidor pode transmitir um componente assim que seus dados estiverem prontos, sem esperar que outros componentes alcancem.
• Os usuários veem o conteúdo carregando um após o outro, melhorando sua percepção de desempenho.

5. Interação Suave com Componentes do Cliente

Agora, o uso de RSCs não implica necessariamente que você deve deixar de usar componentes do lado do cliente. 

Ambos os componentes podem coexistir e ajudar você a criar uma ótima experiência geral no aplicativo.

Pense em uma aplicação de e-commerce. Com SSR, toda a aplicação precisa ser renderizada no lado do servidor.

Em RSCs, no entanto, você pode selecionar quais componentes renderizar no servidor e quais renderizar no lado do cliente.

Por exemplo, você poderia usar componentes do servidor para buscar dados do produto e renderizar a página inicial de listagem de produtos.

Então, componentes do cliente podem lidar com interações do usuário como adicionar itens ao carrinho de compras ou gerenciar avaliações de produtos.

Você deve adicionar a implementação RSC ao seu plano?

Nosso veredito? Os RSCs adicionam muito valor ao desenvolvimento React.

Eles resolvem alguns dos problemas mais urgentes com as abordagens SSR e CSR: desempenho, obtenção de dados e experiência do desenvolvedor. Para desenvolvedores que estão começando a programar, isso tornou a vida mais fácil.

Agora, você deve adicionar a implementação do RSC ao seu roteiro? Vamos ter que ir com o temido — depende.

Seu aplicativo pode estar funcionando perfeitamente sem RSCs. E neste caso, adicionar outra camada de abstração pode não fazer muita diferença. No entanto, se você planeja escalar e acha que RSCs podem melhorar a experiência do usuário para seu aplicativo, tente fazer pequenas mudanças e escalar a partir daí.

E se você precisar de um servidor poderoso para testar RSCs, ative um DreamHost VPS.

DreamHost oferece um serviço de VPS totalmente gerenciado onde você pode implantar até seus aplicativos mais exigentes sem se preocupar com a manutenção do servidor.