Next.JS 12 — As principais novas funcionalidades
Para contextualizar … o que é o Next.JS e em que é que ele se diferencia do React?
Uma aplicação de React, dita tradicional, é renderizada do lado do cliente — CSR (Client Side Rendering) — onde o browser começa apenas com o esqueleto de uma página HTML sem qualquer conteúdo presente. A partir daí, o browser pede o ficheiro de Javascript que contém o código em React para que possa renderizar a página com todo o conteúdo interativo.
No entanto, existem duas grandes desvantagens com CSR:
- O conteúdo não é indexado com consistência pelos motores de busca, nem é lido corretamente pelos bots das redes sociais. Isto é um grande problema porque, dessa forma, é muito difícil que os meta dados da nossa aplicação sejam considerados para a recomendação e apresentação da nossa aplicação aos utilizadores.
- Em termos de performance, é garantido que a primeira vez que o utilizador carrega a página haja um maior tempo de espera e, consequentemente uma pior experiência do utilizador. Podemos estar a falar de uns milissegundos numa aplicação pequena, mas no caso de plataformas mais pesadas, pode ser bastante desagradável para o cliente estar alguns segundos à espera que a aplicação carregue.
No seguimento de um trabalho que desenvolvi para uma unidade curricular da universidade, percebi que o Next.JS é uma Framework que te permite criar uma aplicação em React, mas onde o conteúdo é renderizado do lado do servidor — SSR (Server Side Rendering) — e por isso, a primeira coisa que o browser do utilizador ou um bot de um motor de pesquisa recebem é uma página de HTML completa, com toda a informação da página em questão. Apenas depois de receber esta página, é que o CSR entra na equação para que tudo funcione como se de uma aplicação nativa de React se tratasse.
É o melhor dos dois mundos: temos uma plataforma completamente renderizada para que os bots dos motores de pesquisa consigam exercer a sua função e conteúdo extremamente dinâmico para os utilizadores.
Durante a execução do meu trabalho para a universidade apercebi-me também que existe uma nova versão — o Next.JS 12 — que foi disponibilizada recentemente, no passado mês de Outubro de 2021. Isto despertou-me bastante interesse nesta tecnologia e, por essa razão, achei que seria interessante explorar mais sobre a mesma e perceber quais são as vantagens que estas novidades trazem para o mundo do desenvolvimento web.
Este não será um artigo onde abordarei as funcionalidades base do Next.JS, nem como estas se comparam com React. E, como tal, admite-se que já tens algum conhecimento prévio em Next.JS.
Next.JS 12 — Quais são as novidades?
Esta nova versão da tecnologia foi muito bem recebida pela comunidade de desenvolvimento web, não só por responder às necessidades que esta tinha, mas porque excedeu as expetativas ao ponto de se distinguir das restantes e até desafiar o próprio conceito de full-stack Javascript Framework. Mas porquê? Vamos olhar para as principais funcionalidades do Next.JS 12 e, mais importante ainda, porque é que tu as deverias utilizar:
Compilador em Rust
Middleware
Server Components
1. Compilador em Rust
Para começar, esta versão introduz um compilador de código em Rust, em detrimento de Javascript. Eu não sou nenhum especialista nesta matéria, nem tu precisas de ser! Isto apenas quer dizer que, segundo o que anunciaram, as builds da aplicação passam a ser até 5x mais rápidas. Isto interessa, porque substituindo o Babel (que é o compilador mais utilizado em aplicações de React) por esta nova solução, é minimizado o facto de aplicações grandes, pesadas e complexas demorarem muito tempo a compilar, otimizando o tempo das equipas de desenvolvedores e dos utilizadores finais.
2. Middleware
Este conceito não é novo na indústria do desenvolvimento web, já existe noutras Frameworks como o Express.js que usa Middleware para, por exemplo, intercetar um pedido http, processá-lo de alguma forma antes que o mesmo seja de facto lido. Mas com Next.JS as coisas são um pouco mais complexas.
Por um lado, queres que a tua aplicação seja rápida. A melhor forma de fazer isso acontecer é usar cache para as páginas que são renderizadas no servidor. Mas, no processo, perdemos o conceito de páginas dinâmicas.
Então, do outro lado da moeda, temos SSR que usa um servidor em Node.JS para fazer pedidos a uma base de dados ou a uma API sempre que um novo pedido é recebido. Mas neste caso, é significativamente mais lento e não muito eficiente.
Num mundo perfeito, teríamos ambas velocidade e conteúdo dinâmico ao mesmo tempo. Com a nova versão do Next.JS, a Vercel — empresa por trás da tecnologia — está de facto a liderar esta área. A Vercel lançou algo chamado Edge Functions. Estas são serverless functions, como as Google Cloud Functions, com a diferença de que são implementadas no que eles chamam de Edge. Não entrarei em grande detalhe no que toca à tecnicidade destas funções e, por isso, deixo o link para poderem consultar mais informação sobre a temática. Mas porque é que isto interessa?
É aqui que entra o Middleware. No teu projeto de Next.JS, cria um ficheiro _middleware.js na pasta pages. Lá dentro, podemos exportar uma função chamada middleware. Esta função vai te dar acesso ao pedido que está a chegar e, de alguma forma, alterá-lo. Isto vai acontecer sempre antes do momento de renderização de todas as páginas que tiveres nessa mesma pasta.
Por exemplo, olhando para a figura 3 onde apresento esse ficheiro criado, se precisarmos de verificar em todas as páginas da nossa aplicação que o utilizador está com o login efetuado, podemos utilizar Middleware para o fazer e redirecionar o utilizador para outra página caso não cumpra todos os requisitos.
Assim, em vez de teres que desenvolver esta lógica para cada página individualmente, podes fazê-lo de uma forma muito mais eficiente através de Middleware. Mas ainda como se de um bónus se tratasse, quando publicamos a nossa aplicação, o Middleware é automaticamente lido através de Vercel Edge Functions. Dessa forma, em vez de ter apenas um servidor centralizado de Node.JS, o nosso código de BackEnd é também publicado na tal Edge, estando muito mais próximo do utilizador final e, por isso, é muito mais rápido. É importante mencionar também que a tecnologia está pronta para funcionar em ambientes externos ao Vercel, garantindo que a nossa plataforma pode ser publicada em qualquer outro serviço.
3. Server Components
Server Components permitem-te renderizar, nativamente, código HTML de um componente de React num servidor. Para além disto, tem a vantagem de utilizar http streaming, que possibilita a renderização de uma página web progressivamente no próprio servidor. Isto, na prática, significa que se for necessária informação de uma API ou base de dados para um determinado componente, e depois para outro diferente, e ainda mais um a seguir … não temos que estar à espera que o pedido anterior termine para que o a seguir seja concluído. Entramos no domínio do chamado Progressive Server Side Rendering que, na realidade, abre todo um novo mundo de possibilidades quando falamos de formas para construir uma aplicação Full-stack.
Com Server Components é possível streammar o próprio código HTML de uma forma imediata, através de uma Edge Function, e progressivamente mostrar os resultados de uma forma visual no ecrã dos utilizadores enquanto a informação está a chegar ao cliente.
Para fazer isto podes, também dentro da pasta pages, criar ou modificar o nome de um ficheiro para “xx.server.js” para indicar à Framework que este será um server component. Quando este componente é renderizado, não necessita de nenhum código Javascript do lado do cliente. Significa, portanto, que os ficheiros que o utilizador necessita serão, em princípio, mais leves e demorarão menos a serem transferidos. Para além disso, podemos fazer pedidos a bases de dados ou API’s diretamente neste componente, sem termos de utilizar as funções já conhecidas do Next.JS como getStaticProps ou getServerSideProps.
Obviamente que é muito provável que para além de HTML, também queiras utilizar componentes interativos com recurso a Javascript para o cliente e, por isso, também podes importar componentes normais de React que contenham toda essa lógica. Esses componentes vão ser renderizados tanto do lado do servidor como do cliente.
Reflexão Final
Na minha opinião, a combinação de Middleware com Server Components parece uma forma bastante interessante e atual de construir uma aplicação para a web.
Caso estejas mesmo interessado em explorar este tipo de tecnologia deixo-te aqui um vídeo oficial da Vercel, com explicações mais detalhadas e outros exemplos de como usar as funcionalidades que descrevi neste artigo.
