Capacidade de composição para Jamstack: detalhamento dos termos de front-end

Brian Rinaldi, profissional de relações com desenvolvedores da LaunchDarkly, ficou um pouco intimidado ao falar sobre o significado do Jamstack na Infobip Shift Conference em Miami no mês passado. Isso é compreensível porque no início da programação do dia, Matt Biilmann, o CEO da Netlify que cunhou o termo, já havia definido “Jamstack”.

Como acontece com qualquer disciplina, o frontend tem seu próprio jargão, o que às vezes torna difícil dizer o que é uma mudança ou função tecnológica real e o que é apenas, digamos, jargão de marketing, observou Rinaldi. Em sua palestra, ele se aprofundou nas origens e significados dos termos front-end comuns.

Ele começou com geradores de sites estáticos, que foram o grande sucesso quando ele se tornou um desenvolvedor front-end por volta de 2010. Gerador de sites estáticos (SSG) não era o termo mais comercializável ou compreensível para desenvolvedores e as empresas realmente não acreditaram na ideia de eles, acrescentou.

“Os geradores de sites estáticos pegam vários ativos, pré-renderizam-nos e geram arquivos estáticos que você pode implantar”, explicou Rinaldi. “O problema com isso é que quando você descreve algo como estático, parece antigo… Meu site não é estático, meu site tem coisas interativas, meu site tem tudo isso acontecendo. Não há como usar um ‘gerador de site estático’.”

Além disso, antes do Jamstack, a pilha LAMP era popular, disse Rinaldi. LÂMPADA significa:

• Linux para o sistema operacional;
• Apache para o servidor web;
• MySQL para banco de dados;
• PHP para a linguagem de programação.

“Você pode pensar que meu site usa JavaScript, APIs e marcação, mesmo que eu esteja escrevendo em PHP, (então) isso é Jamstack? Não. Portanto, não é uma pilha muito prescritiva nesse sentido. Foi mais uma especificação conceitual”, explicou ele. “Estávamos fazendo geradores de sites estáticos, com um pouco de JavaScript no lado do cliente que basicamente permite adicionar algumas coisas dinâmicas, talvez até chamar algumas APIs externas. Mas fora isso, era em grande parte estático.”

Em certo sentido, o Jamstack descreveu mais uma visão de longo prazo para o que poderia ser, acrescentou. Gatsby era totalmente novo em 2015 – o ano em que o Jamstack se tornou popular – e os desenvolvedores da web usavam principalmente ferramentas como Hugo e Jekyll e polvilhavam-nas com JavaScript, disse ele.

Então Biilmann surgiu com o Jamstack. Tornou-se popular, assim como Netlify, Vercel e outras empresas que apoiaram a abordagem Jamstack, disse ele.

“A ideia era basicamente, você estava falando sobre sites que ainda eram sites mais ou menos estáticos, mas basicamente expôs a ideia do JAM ser JavaScript, APIs e marcação”, disse ele.

As coisas começaram a mudar por volta de 2022, quando as funções sem servidor se tornaram uma tendência de front-end. O significado de Jamstack também começou a se expandir, como costumam fazer os termos do jargão, disse ele.

“Agora estamos usando funções sem servidor e estamos fazendo mais do que apenas sites estáticos (para) muito disso, talvez tenhamos adicionado renderização no lado do servidor e todo tipo de outras coisas. As coisas ficaram muito mais complicadas”, disse Rinaldi.

Para acomodar a complexidade, Jamstack passou por uma pequena redefinição, disse ele.

“Você deve ter notado que o JAM não está mais em letras maiúsculas porque não se trata apenas de JavaScript, APIs e marcação”, disse ele. “Na verdade, houve muita confusão na época sobre isso. … Perder a sigla fazia sentido, mas também ampliamos a definição. Então essa evolução da terminologia de que falamos, onde o jargão tende a se expandir para atender a todas as coisas que são acrescentadas. E então, neste ponto, tornou-se… muito mais vago.”

Depois vieram os frameworks JavaScript full-stack, como Next.js e Nuxt, e empresas como Vercel e Netlify começaram a oferecer suporte a funções serverless e funcionalidades de backend.

“Eu olhei para Jamstack como um termo genérico, e então tínhamos todos esses outros termos que se enquadravam nele”, disse ele. “Neste ponto, Jamstack é meio amplo e difuso, mas temos muitos outros jargões mais específicos que descrevem todas as técnicas e tudo que está sob esse guarda-chuva.”

Desacoplamento e arquitetura sem cabeça

Uma das ideias sobre as quais Biilmann falou na Shift foi a dissociação. A dissociação é difícil de explicar, mas é mais fácil de entender quando se considera a alternativa à dissociação, disse Rinaldi.

“Estávamos tentando criar uma alternativa para essa arquitetura monolítica” do WordPress, que ele chamou de “exemplo canônico de arquitetura monolítica” porque exigia que tudo mudasse no frontend sempre que houvesse uma mudança no backend, porque frontend e backend eram tão fortemente acoplados. Os desenvolvedores queriam dissociar o backend do frontend.

“Não estamos apenas tentando oferecer suporte a um aplicativo da web, estamos tentando oferecer suporte a aplicativos móveis, aplicativos de voz ou outros tipos de aplicativos”, disse Rinaldi. “Não quero ter que manter um conjunto de conteúdo aqui para meu aplicativo da web, e então repetir a mesma coisa para meu aplicativo móvel em um sistema diferente porque eles não podem se comunicar. A arquitetura desacoplada nos permitiu ser um pouco mais flexíveis na forma como construímos as coisas, mas também oferecer suporte a vários front-ends diferentes com o mesmo back-end.”

Isso leva a outro termo comumente cogitado: Headless.

“Na época, CMSs monolíticos (eram) a grande novidade (…) como o Drupal, que fazia o frontend e o backend”, disse ele. “Não havia como dissociar essas duas peças. Então, empresas como a Contentful e outras tiveram a ideia de que talvez precisássemos apenas do backend do sistema de gerenciamento de conteúdo e (…) você pode conectar qualquer frontend que desejar.”

Então, o desenvolvimento web obtém conceitos como comércio sem cabeça, que é essencialmente o back-end de um sistema de comércio eletrônico sem vínculo com o front-end, explicou ele. Isso permite que o desenvolvedor coloque qualquer front-end que desejar nesse back-end – e é por isso que é chamado de headless, explicou ele.

Pré-renderização e muitas siglas

“Pré-renderização é honestamente uma palavra chique para dizer que algo está estático”, disse Rinaldi. “Vou explicar por que existe uma razão legítima para usar esta versão mais complicada – (…) pré-renderização, em oposição à estática – é uma coisa melhor, e isso porque quando você entra nos tipos de renderização, as coisas ficam um pouco complicadas.”

Os termos relacionados incluem CSR para renderização do lado do cliente, renderização de conteúdo e aplicativos de página única ou SPAs, disse ele.

“Seu aplicativo de página única basicamente renderizava tudo em JavaScript no cliente, no navegador”, disse ele. “Em seguida, usaríamos hidrato – outro jargão – hidrataríamos o aplicativo com novo conteúdo, basicamente chamando dados dos dados de conteúdo, a API de back-end, e então hidratando-os no cliente. Mas toda essa parte de renderização foi feita no cliente.”

Já com a renderização no lado do servidor, em vez de hidratar o cliente o tempo todo, cada solicitação enviada renderiza novamente a página nos servidores e a envia, acrescentou.

“Eu brinco que a renderização no lado do servidor é o que venho fazendo e comecei a construir sites há mais de 25 anos. Estávamos fazendo renderização no lado do servidor, mas se você falar com os desenvolvedores agora, você pensaria que isso foi (primeiramente) tentado pelo React há dois anos”, disse ele. “Estamos mudando muito da renderização do lado do cliente para a renderização do lado do servidor porque o desempenho da renderização de conteúdo, especialmente em dispositivos – os tamanhos dos pacotes e todas essas outras coisas – pode causar muitos problemas. Então agora você notará que os frameworks, até mesmo o React, estão começando a migrar para a renderização no lado do servidor com coisas como React Server Components e assim por diante.”

Muitas estruturas mais recentes concentram-se exclusivamente na renderização do lado do servidor, acrescentou. SSG, ou geração de site estático, remonta à ideia de pré-renderização, afirmou ele.

“A razão pela qual gosto de pensar nisso como pré-renderização é porque a geração de sites estáticos faz com que pareça diferente da renderização do lado do servidor”, disse ele. “Não é tão distinto quanto você imagina. Basicamente, a geração de sites estáticos é a renderização do lado do servidor no momento da construção e, em seguida, o envio. … Em última análise, funciona da mesma forma.”

Outros termos semelhantes que ele citou tentam descrever basicamente o mesmo conceito – o que ele chamou de “renderização diferida” – mas cada um é feito com uma implementação ligeiramente diferente:

• ISR, ou Regeneração Estática Incremental, que é uma técnica usada em estruturas como Next.js para criar uma abordagem híbrida entre geração de site estático (SSG) e renderização do lado do servidor (SSR).
• DPR significa renderização persistente distribuída, que pré-renderiza conteúdo em uma rede distribuída de servidores para garantir que o conteúdo esteja disponível 24 horas por dia, 7 dias por semana. Netlify introduziu o conceito em 2021. Smashing Magazine explicou a diferença entre ISR e DPR.
• DSD, que significa Declarative Shadow DOM (DSD). Ele traz o shadow DOM para o servidor.

“A ideia aqui é que se os geradores de sites estáticos e a renderização no servidor tivessem um filho, seria este”, disse ele sobre ISR, DPR e DSD. “Basicamente, é a primeira chamada para uma página, vou renderizá-la no servidor, armazená-la em cache (e), em alguns casos, até mesmo adicioná-la como um ativo estático à saída real do site. Mas isso só é feito sob demanda. É por isso que chamo isso de renderização adiada, porque é como se estivéssemos basicamente renderizando a página estática, mas fazendo isso na primeira solicitação e, em seguida, servindo a todos os outros que vierem depois dessa versão estática.”

Isso permite que os desenvolvedores reduzam o tempo de construção, ao mesmo tempo que obtêm os benefícios da geração de estado estático – que será rápida, acrescentou.

Combinável e MACH

Composable é um termo usado frequentemente pelo Netlify, e alguns desenvolvedores o veem como um termo de marketing que basicamente significa “uma versão empresarial do Jamstack”, disse Rinaldi. Isso não é verdade, disse ele.

“É realmente muito mais focado no back-end”, disse ele. “Na verdade,… ele nem está preocupado com o tipo de aplicativo que você está construindo no frontend. Você poderia ter uma arquitetura combinável que se comunicasse com um aplicativo móvel, ou poderia fazer com que ela se comunicasse com um aplicativo web.”

Enquanto Jamstack estava muito focado em como os desenvolvedores constroem um site, a composição tem uma visão mais ampla – embora seja mais uma prática para grandes organizações, acrescentou.

“Eu tenho todas essas APIs diferentes, agora preciso criar todo esse tipo de padrão de back-end para front-end, onde posso ter uma camada no front-end que está apenas tentando unir todas as minhas APIs de back-end”, disse ele. “Agora precisamos obter os dados do cliente da API do cliente para obter o ID do cliente e depois passá-lo para a API de pedidos para receber os pedidos. Você está entrelaçando essas coisas complexas, geralmente provenientes de sistemas e APIs diferentes. E foi difícil juntar tudo isso.”

A capacidade de composição une essas peças, facilitando a inserção das peças. As plataformas de composição tendem a usar GraphQL porque é a maneira mais comum de unir várias APIs em uma API reutilizável, acrescentou.

“Você pode fazer (…) composable e Jamstack juntos. Eles não são mutuamente exclusivos: seu back-end combinável pode se conectar a um aplicativo da web Jamstack, eles trabalham juntos”, disse Rinaldi. As pessoas costumam reclamar que é “muito empresarial”, acrescentou ele, mas isso é porque resolve um problema de nível empresarial.

Por fim, ele explicou o termo MACH, um acrônimo para microsserviços, API-first, SaaS nativo da nuvem e headless. A arquitetura MACH é combinável e modular, de acordo com a MACH Alliance. É frequentemente usado com o termo composição. MACH é uma “versão um pouco mais prescritiva” da composibilidade, disse ele.

A postagem Composability to Jamstack: detalhando os termos do front-end apareceu pela primeira vez em The New Stack.