[vc_row][vc_column][vc_column_text]Quando falamos sobre frameworks que estão em ascensão (ou o famoso hype), é impossível não citarmos o Next.js. Mas, afinal, do que exatamente esse framework é capaz, e como ele se compara a outros frameworks?
[adrotate banner=”4″]
Inicialmente lançado em 25 de outubro de 2006, Next.js surgiu como um framework React, com a proposta de facilitar a vida do desenvolvedor, trazendo várias features focadas em resolver problemas recorrentes. Como um roteamento dinâmico, SSR (server side rendering) e *SSG (static*site generation), roteamento pelo lado do cliente, utilizando funções como o prefetch para carregamentos mais rápidos, suporte ao CSS e Sass, ou qualquer outra biblioteca CSS javascript, suporte para Fast Refresh e rotas API para criação de endpoints e funções serveless.
Mas, afinal, do que o Next JS é capaz?
O Next.js é um servidor Node que funciona como uma camada entre o código React e o browser (cliente). Ele faz o intermédio da renderização dos componentes e apresentação deles para o cliente e conta com diversas features que serão listadas abaixo.
SSR (Server-side Rendering)
Como o próprio nome sugere, esse processo nada mais é do que a renderização dos elementos HTML do lado do servidor. Portanto, isso traz algumas vantagens e desvantagens em relação ao CSR (client server rendering), que listamos abaixo:
Vantagens
1. Segurança de dados
Muitas vezes, quando fazemos “queries” no banco de dados, trazemos algumas informações adicionais ou privadas que não deveriam estar disponíveis para os usuários. Neste caso, o SSR nos dá uma proteção adicional, uma vez que os dados estão sendo armazenados no servidor Node do Next.js e apenas as informações que devem ser mostradas estarão presentes no lado do cliente.
2. Velocidade de carregamento das páginas
Ao renderizar uma página utilizando o CSR, o browser deve fazer o download dos arquivos javascript para então executá-los. Assim, arquivos grandes podem fazer com que o carregamento da página demore mais. Todavia, isso não ocorre ao utilizar o SSR, uma vez que o carregamento é feito pelo lado do servidor e apenas o resultado da execução é exibido no cliente. Alguns testes indicam grandes melhorias em performance.
3. Melhor previsão de performance e processamento
Uma vez que a renderização é feita pelo lado do servidor e sabemos as especificações dele, uma medição de performance, em todos os dispositivos que se conectaram aquele website, será muito precisa!
4. Melhor integração com SEO (Search Engines Optimization)
Atualmente, ferramentas de busca têm tido um difícil trabalho ao tentar indexar páginas que utilizam CSR. Isso porque, com esse tipo de renderização, toda a informação de websites advém da execução de códigos em javascript. Crawlers responsáveis por adquirir informações da página e indexá-las para busca, em sua grande maioria, o fazem desabilitando o javascript e pegando apenas informações provindas do HTML, uma vez que baixar esses arquivos e executá-los seria muito custoso para as SE (search engines).
Como podemos observar, esse problema é facilmente contornado ao utilizar SSR, já que o conteúdo apresentado ao cliente é efetivamente HTML, que foi renderizado pelo código javascript no lado do servidor. Vale lembrar que o SSR não é “bala de prata”, ou seja, existem momentos em que sua utilização não é necessária ou recomendada. Logo, algumas desvantagens devem ser citadas.
Desvantagens
1. Maior gasto com servidores
Se uma página é demandada de muitas renderizações, isso pode ser custoso para o servidor e acaba impactando o gasto financeiro para manter a aplicação.
2. Incompatibilidade com algumas bibliotecas
Algumas bibliotecas que utilizam objetos window ou document podem não ser compatíveis com o SSR.
SSG (Static Site Generation)
Como o SSR, o SSG executa o javascript no lado do servidor e apresenta para o usuário o HTML compilado. A diferença ocorre no momento da renderização, que acontece em tempo de compilação e não quando as requisições são realizadas (SSR). Em decorrência disto, suas vantagens e desvantagens se assemelham muito.
Otimização Estática Automática
Next.js é capaz de determinar automaticamente se uma página é estática. Fazendo, assim, com que ele possa criar aplicações híbridas que contém SSR e SSG. Um dos principais benefícios disso é que páginas que foram otimizadas não precisam de nenhuma computação do lado do servidor, possibilitando entrega de dados de múltiplos CDN (Content Delivery Network), o que resulta em um carregamento extremamente rápido para os usuários.
Importação dinâmica e separação de códigos (code splitting)
Componentes só são importados e baixados quando são apresentados em tela. Com isso, o processo de espera de requisição é ainda mais veloz.
Routing
Next.js conta com um sistema de rotas integrado ao framework, quando um arquivo ou uma pasta é adicionada à pasta pages, o seu nome fica automaticamente disponível como uma rota; e arquivos com o nome index são automaticamente roteados para o nome da pasta “mãe”. Além disso, pastas aninhadas dentro de outras pastas também são roteadas.
-`pages/index.js` -> `/`
-`pages/blog/index.js` -> `/blog`
-`pages/blog/first-post.js` -> `/blog/first-post`
-`pages/dashboard/settings/username.js` → `/dashboard/settings/username`
Também é possível indexar rotas dinâmicas ao utilizar colchetes, que permitem adquirir parâmetros pelo nome que está no interior dos colchetes.
-`pages/blog/[slug].js` → `/blog/:slug` (`/blog/next`)
No exemplo acima, caso fosse acessado a rota /blog/next, o valor que recebido pelos parâmetros seria:
{ "slug": "next"}
De maneira análoga, é possível pegar todos os caminhos referentes aquela pasta.
-`pages/post/[...slug].js` // consegue pegar as rotas -> 'post/a', 'post/a/b', etc.
Tendo como valor recebido nos parâmetros **um array, da seguinte forma:
-'post/a' -> {"slug": ["a"]}
-'post/a/b' -> {"slug": ["a", "b"]}
API Routes
Next.js conta com rotas de API, que servem para uma conexão com a API do framework, análogo as rotas da aplicação, pastas aninhadas dentro de page/api são mapeadas para a rota /api/*, sendo tratadas como endpoints.
De toda forma, é importante colocarmos em evidência que a API do Next não deve substituir um Back-end completo, e sim facilitar algumas implementações no lado do Front-end. Alguns exemplos já integrados ao Next.js são: a autenticação social, e a facilidade de implementações do chamado JAMStack, integrando headless CMSs e possibilitando a criação de aplicações completas com a utilização de API externas.
Next.js vs React
Uma vez que Next.js é um framework de React, é provável que surja a dúvida entre qual framework escolher ao desenvolver os seus projetos. Nesse tópico serão comparadas essas duas ferramentas para elucidar essas incertezas.
Facilidade dar início a um projeto
Tanto o React quando o Next.js possuem maneiras fáceis de se iniciar um projeto, com uma simples linha de código. Ambos estão prontos para execução.
-NEXT -> yarn create next-app
-REACT -> yarn create react-app
Do mesmo modo, uma vez que Next.js tem um roteamento automático, menos linhas de códigos precisam ser escritas.
Performance
Com features como SSR e SSG, otimização automática, otimização de imagens (Next 10) e separação de código (code splitting), o Next.js ganha em performance facilmente, embora seja possível otimizar o React de diversas maneiras. Tudo isso deve ser feito após a inicialização do projeto.
Comunidade
Há diversos motivos para que a comunidade seja um fator muito importante ao se escolher um framework. Afinal, nenhum desenvolvedor gosta de encontrar um problema que ninguém mais se deparou. Em virtude disso, a comunidade do React é de longe a maior e conta com mais tutoriais.
Todavia, vale salientar que Next.js está em grande ascensão e que, cada vez mais, a sua comunidade cresce. Além disso, Next.js é um framework de React, então, problemas que podem acontecer muitas vezes estão intimamente atrelados.
Veja também:
Extensões VS Code Que Você Precisa Conhecer.
Biblioteca de Artigos Sobre Desenvolvimento de Software.
Conclusão
Levando em consideração todos os dados apresentados neste artigo, é fácil perceber o poder que o Next.js traz consigo e suas implicações. Todavia, devemos sempre lembrar que Next.js é um framework de React, e que grande parte de suas implementações vem dele. Portanto, uma boa base é extremamente necessária.
Além disso, ter um bom entendimento de SSR, SSG e CSR é de extrema valia, uma vez que suas corretas implementações impactam fortemente no desempenho e otimização da aplicação.[/vc_column_text][/vc_column][/vc_row]
[adrotate banner=”5″]
