
A **Jamstack** é uma arquitetura criada para construir sites mais rápidos, que escalam com facilidade e que são mais seguros, segundo o [site oficial](https://jamstack.org). Antes mais conhecidos como "sites estáticos", esses sites são geralmente um conjunto de arquivos HTML, CSS e JS que conversam com o servidor apenas quando necessário.

Um dos motivos para a Jamstack estar se tornando tão popular é a explosão de ferramentas poderosas que permitem criar sites que vão além do que tradicionalmente sites "estáticos" faziam. Agora existem diversos CDNs especializados em entregar esses sites rapidamente para usuários de qualquer lugar do mundo, ferramentas para integração e publicação contínua, CMSs Headless perfeitos para sites Jamstack e ferramentas para criá-los sem dor de cabeça.

Neste guia completo para iniciantes, eu vou te explicar os porquês de usar esta arquitetura, ferramentas para construir e publicas sites Jamstack e também suas desvantagens.

## Arquitetura de um site JAMStack

Sites Jamstack utilizam uma arquitetura diferente de sites que utilizam um servidor backend tradicional. Sites que utilizam servidores – como Wordpress, Laravel ou Rails – geram uma resposta para cada vez que um usuário requisita uma nova página. Já sites Jamstack têm todas as suas páginas pré-renderizadas antes de serem publicadas e podem ser servidos diretamente de uma Content Delivery Network (CDN) assim como já fazemos com imagens, vídeos e outros arquivos estáticos.

O fato de sites Jamstack serem compilados para arquivos estáticos não os torna menos capazes do que sites renderizados no servidor. Um grande motivo para o pessoal da [Netlify](https://www.netlify.com/) ter criado o termo "Jamstack" foi fugir do termo "estático" – como disse Mathias Biilmann [em um episódio do _JAMStack Radio_](https://www.netlify.com/blog/2016/09/15/the-jamstack-origin-story/). Usando JavaScript e consumindo APIs, sites Jamstack são bastante dinâmicos e utilizam de arquivos estáticos apenas como uma forma de remover a necessidade de um servidor mais complexo.

As ferramentas utilizadas para criar sites Jamstack são comumente chamadas de geradores estáticos. Os geradores estáticos mais utilizados são o Hugo, Next.js e Gatsby. Para gerenciar o conteúdo destes sites, normalmente utiliza-se arquivos Markdown ou um Headless CMS.

## Por que construir um site usando Jamstack?

A primeira vantagem de utilizar esta arquitetura é a **performance**. Como o frontend já foi pré-renderizado antes da publicação e estes arquivos normalmente são servidos direto de uma CDN, o tempo de resposta de um site Jamstack tende a ser muito baixo. Utilizando ferramentas modernas como [Gatsby](#gatsby), o JavaScript utilizado dentro de cada página é altamente otimizado e leve – assim como o CSS é reduzido a apenas o necessário. É inclusive bastante comum ver sites Jamstack atingirem altas pontuações no [PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/?hl=pt-br).

Uma outra vantagem de uma arquitetura baseada em arquivos estáticos é a **escalabilidade**. Enquanto sites tradicionais baseados em um servidor dinâmico dependem de camadas de cache para entregar páginas com rapidez em momentos de altas cargas de tráfego, sites Jamstack já foram pré-renderizados. Também não é necessária a criação de lógicas complexas de invalidação de cache, já que a arquitetura e os geradores estáticos tomam conta disto por você.

Como sites Jamstack são publicados como uma coleção de arquivos estáticos, eles também são **facilmente portáveis** para diferentes provedores como AWS, Netlify, Vercel e Google Cloud Platform.

## Principais ferramentas para construir um site Jamstack

Nos últimos anos muitas ferramentas surgiram para construir sites com esta arquitetura, incluindo o Next.js, Gatsby, Hugo e outros geradores estáticos. Existem opções para quem quer criar sites utilizando frameworks JavaScript como React e Vue ou até geradores estáticos com engines de templates mais tradicionais como Hugo e Jekyll.

Escolher entre todas essas ferramentas pode ser uma tarefa bastante difícil. Abaixo eu trouxe uma lista com as opções mais comuns e que eu recomendo para seu próximo projeto. Além destas três, existem muitas outras ferramentas listadas em [jamstack.org/generators/](https://jamstack.org/generators/).

### Next.js

O [Next.js](https://nextjs.org/) evoluiu muito desde sua primeira versão. Na minha opinião, ele é agora a ferramenta mais versátil para criar sites Jamstack. Criado pela Vercel, o Next.js é um framework JavaScript bastante conhecido que usa como base o React e o Node.js.

Com uma arquitetura simples e ferramentas de compilação pré-configuradas, você rapidamente poderá criar sites Jamstack com o Next.js. Além de páginas pré-renderizadas, você pode utilizá-lo também para criar páginas geradas no servidor e até rotas de API com Serverless Functions.

Toda a complexidade de configurar ferramentas como Webpack e Babel, otimizar bundles para publicar em produção, configurar um servidor para renderizar componentes React e criar todo um backend para algumas pequenas rotas de API somem ao usar o Next.js.

Se você utiliza Vue ao invés de React, também vale a pena conferir o [Nuxt.js](https://nuxtjs.org/).

### Gatsby

O [Gatsby](http://gatsbyjs.com/) é uma abordagem diferente para criar sites com React. Sua ideia principal é juntar uma arquitetura baseada em plugins com o poder do GraphQL (uma linguagem de consulta de dados).

Com mais de 2000 plugins, é bastante simples integrar o Gatsby com diferentes fontes de dados como arquivos Markdown, Headless CMSs, planilhas, e bancos de dados. Após adicionar e configurar um plugin, estes dados estarão disponíveis no GraphQL.

Assim como o Next.js, o Gatsby faz um grande trabalho por você para exportar um site Jamstack com alta performance sem que você tenha que passar muito tempo configurando o processo de compilação.

O [sistema de temas do Gatsby](https://www.gatsbyjs.com/plugins/?=gatsby-theme) também é bastante interessante. Temas do Gatsby juntam configurações e plugins em um único pacote, oferecendo uma forma ainda mais simples de criar sites como blogs, lojas e wikis.

### Hugo

Mais como um gerador de sites tradicional, o [Hugo](https://gohugo.io) é um projeto em Go criado para ser extremamente rápido e versátil para criar sites estáticos.

Sem instalar plugins você pode trabalhar com diversos tipos de conteúdo, taxonomias e conteúdo dinâmico de APIs. Além disso, o sistema de templates do Hugo é recheado de utilitários para criar layouts diferentes para cada página, trabalhar com SEO, internacionalização e até exportar o seu projeto para JSON ou AMP.

Existe uma grande quantidade de temas para Hugo, que vão desde os criados para sites pessoais até temas para criação de apresentação de slides. Ao contrário do Gatsby e do Next.js, Hugo não usa React como sua linguagem de templates o que pode ser uma grande vantagem para quem não planeja muitas interações renderizadas no lado do navegador ou não quer prender o seu site nesta biblioteca JavaScript.

## Os melhores Headless CMSs para seu projeto

Para o conteúdo que preenche os sites Jamstack, é bastante comum utilizar um Headless CMS. Estes CMSs são diferentes de CMSs mais tradicionais como o WordPress já que eles não tocam na implementação da interface de usuário que mostrará o conteúdo. Em vez disso, eles oferecem uma API para que você possa consumir e renderizar o conteúdo por conta própria.

A grande vantagem de utilizar um Headless CMS é separar bem a criação do conteúdo do código do site. Dessa forma, times diferentes dentro de um projeto podem trabalhar no código e no conteúdo. Headless CMSs também tendem a ser bastante flexíveis em como você pode organizar o conteúdo e oferecem hospedagem de arquivos como imagens e vídeos.

Alguns destes CMSs são o Netlify CMS, Strapi e Ghost. Você pode conferir uma lista completa em [jamstack.org/headless-cms/](https://jamstack.org/headless-cms/).

### Netlify CMS

Feito pela empresa que cunhou o termo Jamstack e têm trabalhado para difundir esta arquitetura, o [Netlify CMS](https://www.netlifycms.org/) é uma solução prática para criar conteúdo para sites Jamstack. Nele todo o seu conteúdo é armazenado dentro de um repositório git, te permitindo controlar o versionamento de conteúdo integrado com o código.

Além de ser open-source com uma licença MIT, o Netlify CMS pode ser extendido para acomodar as necessidades de edição de conteúdo do seu projeto. Como ele roda como um webapp embutido em seu site, você não precisa de um servidor para hospedá-lo.

### Strapi

Uma opção ainda mais poderosa para usar como Headless CMS é o [Strapi](https://strapi.io/). Com um plano gratuito praticamente completo e seu código-fonte open-source, o Strapi é uma boa alternativa para você auto-hospedar um Headless CMS.

Dentre as suas funcionalidades estão tipos de conteúdo ilimitados, APIs REST e GraphQL, armazenamento de arquivos e mídia, assim como controles de acesso de usuários. Você pode hospedar sua instância do Strapi em servidores de sua escolha como na AWS, Digital Ocean ou Heroku.

### Ghost

Mais um projeto de código aberto, o [Ghost](https://ghost.org/) é um CMS tradicional que também oferece APIs para consumo de conteúdo por geradores de sites Jamstack.

Além de poder criar seu conteúdo, escolher um tema, gerar seu site e hospedá-lo com o serviço de hospedagem oficial, você pode controlar tudo por conta própria assim como no Netlify CMS e Strapi. A grande diferença entre eles e o Ghost é que ele é bastante especializado em criar sites no estilo de blogs ou publicações de jornal.

O Ghost também conta com uma [grande quantidade de integrações](https://ghost.org/integrations/) para facilitar a sua vida e permitir que você construa um site bastante completo sem ter que sequer escrever uma única linha de código.

## Como publicar sites Jamstack

Sites Jamstack podem assumir diversas formas, dependendo das funcionalidades que você implementar e das ferramentas que utilizar. Porém, você provavelmente não precisará muito mais do que uma CDN para hospedá-los. Algumas boas opções de serviços que se especializaram em hospedar este tipo de sites são: [Netlify](https://www.netlify.com/) e [Vercel](https://vercel.com/).

As duas plataformas são muito similares e oferecem uma forma fácil de criar fluxos de integração contínua para seu repositório git e publicar arquivos estáticos ou funções serverless em produção. Com diversas funcionalidades configuradas por você, é relativamente simples apontar uma destas plataformas para o repositório do seu projeto, definir um domínio e publicar seu site.

Uma das funcionalidades que mais me chamou atenção nos dois foi o "deploy atômico". Para cada commit no seu repositório, o Netlify e o Vercel criam um novo deploy e um link que pode ser acessado pra sempre. Isso torna simples pré-visualizar mudanças antes de irem para produção ou comparar diferentes versões antigas do seu site.

Além dos serviços oferecidos pelos dois, a Netlify se destaca com alguns adicionais. Lá você pode criar fluxos de otimização de arquivos como .html e imagens, testes A/B, integrar com um Analytics do lado do servidor, implementar autenticação e até guardar dados de formulários sem criar APIs manualmente.

Apesar destas platformas tornarem muito fácil a publicação de sites Jamstack, você não precisa utilizá-las. Em vez de uma plataforma tudo-em-um, pode fazer sentido para você publicar e hospedar o seu site em lugares como na AWS S3 ou até em VPSs da Digital Ocean.

## Desvantagens de sites Jamstack

Todas as arquiteturas vêm com vantagens e desvantagens. Já que o foco do Jamstack é em pré-renderizar páginas e utilizar JavaScript consumindo APIs para torná-las dinâmicas, sites que possuem páginas com conteúdo que mudam muito não são os melhores candidatos para esta arquitetura.

Alguns exemplos de sites que seriam melhor implementados com outra arquitetura são:

- Webapps onde o conteúdo muda de usuário para usuário em experiências logadas, principalmente os que expõem conteúdo de acordo com níveis diferentes de permissão
- Sites em que o conteúdo se baseia em computação do lado do cliente, como ferramentas de edição de fotos ou blocos de notas.

Entretanto, isso não significa que as ferramentas que mencionamos aqui também não sejam úteis para estes tipos de sites. Com o Next.js, por exemplo, você pode implementar APIs, integrá-las na criação da parte estática do seu site e criar experiências que executam apenas no navegador – tudo integrado em uma arquitetura simples e pré-configurada.

Mesmo que você não esteja criando um site que combina perfeitamente com a arquitetura Jamstack, vale a pena utilizar alguns dos seus conceitos – como a pré-renderização de conteúdo – para melhorar a performance do seu projeto.

## Continue aprendendo

Neste artigo eu falei um pouco sobre o que é a arquitetura Jamstack, porquê utilizá-la, indiquei algumas ferramentas e também mostrei algumas desvantagens. Existe bastante conteúdo sobre o Jamstack, principalmente em inglês. Se você quiser continuar aprendendo, dá uma olhada nesta lista de recursos para seus estudos:

- [NextJS, Gatsby ou Create React App? Entendendo os conceitos de SSR, SSG e SPA](https://willianjusten.com.br/nextjs-gatsby-ou-create-react-app-entendendo-os-conceitos-de-ssr-ssg-e-spa/)
- [The issues with JAMStack: You might need a backend](https://www.browserlondon.com/blog/2020/04/20/issues-with-jamstack-you-might-need-backend/)
- [Jamstack Best Practices](https://jamstack.org/best-practices/)
- [The Jamstack origin story](https://www.netlify.com/blog/2016/09/15/the-jamstack-origin-story/)
- [Gatsby.js Tutorials](https://www.gatsbyjs.com/tutorial/)
- [Create a Next.js App](https://nextjs.org/learn/basics/create-nextjs-app)


Conheça mais sobre a arquitetura feita para construir sites mais rápidos.

O que é a Jamstack? Guia completo para iniciantes


_Este artigo também está disponível como [slides][slides]._

Com cerca de 360 propriedades, não faltam muitas coisas para você conseguir
estilizar basicamente qualquer coisa usando a versão atual do CSS. O maior
problema na verdade está como solucionar problemas de estilização de uma forma
escalável. Escalável para que seu código seja flexível o suficiente para não
ter que ser completamente reescrito no próximo redesign que com certeza vai
acontecer, e também escalável para que seu time possa continuar mantendo
o código por muitos anos.

Em meio a tantos frameworks diferentes e técnicas como Flexbox, Grid CSS,
floats, e até CSS-in-JS, é difícil olhar através do superficial e achar as boas
práticas e hábitos essenciais para escrever CSS que dura.

Após muitos anos como desenvolvedor front-end acabei desvendando alguns
hábitos que me levam a escrever CSS mais escalável. Agora, quase sempre que
encontro estilos difíceis de lidar ou que dão bastante trabalho para refatorar,
percebo que eles não seguem um dos três princípios básicos que vou te ensinar.

Aprender a escrever CSS escalável é essencial, já que independente da sua
abordagem para criar interfaces de usuário na web, você vai precisar
estilizá-la. E, por mais bonita e bem planejada que seja, esta mesma interface
de usuário vai passar por muitas mudanças conforme o produto é alterado. Novas
funcionalidades precisam de espaço. O posicionamento de alguns elementos são
trocados para melhorar a experiência do usuário. Novas páginas são criadas.
Estilos mais "modernos" são propostos. Três hábitos podem nos ajudar a passar
por tudo isso com menos dor de cabeça.

## Abrir mão do posicionamento

Com CSS nós podemos posicionar qualquer elemento em qualquer lugar. Apesar
disso, não é sempre que devemos usar `position: fixed` ou `position: absolute`
para controlar exatamente em qual pixel na tela um elemento estará. Abrir mão
do posicionamento de um elemento vai ainda mais longe do que isso.

Cada vez que tentamos controlar o posicionamento de um elemento, este elemento
se torna menos reutilizável em diferentes contextos e talvez precise ser
refatorado quando o layout das páginas em que são utilizados forem alterados.

Vamos imaginar que temos um componente `Botao`. Por componente, eu quero dizer
um conjunto de HTML, CSS e JS que trabalham juntos – usando ou não um
framework. Este componente geralmente é utilizado em conjunto com outros botões
na nossa interface de usuário. Para posicionar estes componentes poderíamos
recorrer a seletores CSS como `.botao + .botao`, adicionando um pouco de
`margin` entre cada botão. Dessa forma, qualquer lugar que usasse `Botao` teria
o espaçamento entre eles padronizado.

O problema dessa solução é que ela não é escalável. No momento que quisermos
trocar um `Botao` por um `Link`, este espaçamento não seria mais aplicado.
Conforme estas excessões se tornam a regra, poderíamos acabar com diversos
seletores muito específicos: `.botao + .link`, `.link + .botao` e
`.link + .link`. É inviável tentar lidar com espaçamento automático entre
componentes porque não temos certeza de como eles serão utilizados em conjunto
no futuro.

![imagem com um botão e um link sem espaçamento entre
eles](/posts/tres-habitos-css-escalavel/botao-botao.png)

Uma forma melhor de espaçar componentes e evitar este problema com seletores
específicos é dar ao componente que os engloba a responsabilidade de
espaçá-los. Um componente de `Fomulario`, por exemplo, poderia ditar os estilos
de espaçamento entre cada `Botao`, `Link` e `Input`. Controlando o espaçamento
de cima pra baixo na hierarquia dos componentes torna o CSS muito mais
escalável por permitir que componentes de baixo nível possam ser utilizado em
contextos completamente diferentes ao mesmo tempo sem que eles tenham que ter
estilos específicos para cada um desses contextos.

## Abrir mão do tamanho

Assim como abrir mão do posicionamento, abrir mão do tamanho também é um ótimo
hábito para escrever CSS escalável. Em uma página de galeria, por exemplo, nós
poderíamos estilizar o componente `Figura` de tal forma que seu `width` estaria
fixo em `300px`, já que este é o tamanho exato deste elemento no design. Porém,
se decidirmos utilizar `Figura` dentro de um elemento maior ou menor, nós
teríamos problemas.

Ao abrir mão do espaçamento, delegamos ao máximo a definição real do tamanho de
um elemento na tela. Isso significa que quase todos os seus componentes seriam
estilizados com `width: 100%`, de modo que quem os engloba pode decidir seu
tamanho real final.

![images de uma galeria de imagens com Figura em diversos
tamanhos](/posts/tres-habitos-css-escalavel/galeria-diversa.png)

Existem alguns casos em que não é possível abrir mão do tamanho dos nossos
componentes. É, por exemplo, muito difícil estilizar um componente complexo
para comportar tamanhos muito grandes e muito pequenos sem o uso de _media
queries_. Não existe hoje uma forma de estilizar um componente baseado em seu
tamanho na tela, já que ainda não temos algo como [Container
Queries][container-queries] no CSS.

Mantenha sempre em mente que <mark>nenhuma solução técnica vem sem
desvantagens</mark>. Para componentes assim, talvez o ideal seja ter diferentes
versões dos seus estilos que podem ser utilizadas usando uma classe no elemento
principal para definir uma versão "enxuta" ou "completa".

## Deixar o conteúdo fluir

Conteúdo é quase sempre o centro de um design. E em muitas interfaces de
usuário dinâmicas, é muito difícil saber ao certo o tamanho de um texto, imagem
ou vídeo. Botões podem ter mais texto do que cabe em apenas uma linha. Imagens
talvez sejam estreitas e não quadradas. Títulos podem ter palavras que não
cabem inteiras na largura de um dispositivo móvel. Conteúdo é dinâmico, e seus
componentes devem deixá-lo fluir.

Existem basicamente duas maneiras de lidar com a diversidade de conteúdo:
forçar o conteúdo para se adaptar ao seu componente (abordagem controlada)
e adaptar o componente ao conteúdo (abordagem fluída).

### Abordagem controlada

Para forçar o conteúdo a se adaptar a um componente, podemos usar `overflow: hidden`, `width` e `height` fixos, `text-overflow: ellipsis` e muitas outras
regras. Esta abordagem normalmente é necessária quando temos que manter um
balanço e prevenir que um conteúdo gerado pelos usuários quebre a interface.

![imagem de uma figura com sua descrição incompleta](/posts/tres-habitos-css-escalavel/chicago-controlada.png)

O problema de tentar controlar o conteúdo é que uma mudança nos requerimentos
deste conteúdo pode nos forçar a refatorar todos os componentes que não se
adaptam ao conteúdo.

### Abordagem fluída

Uma outra forma de lidar com conteúdo é com uma abordagem fluída. Se quase
todos os nossos componentes seguirem essa abordagem, teremos uma interface de
usuário flexível que se adapta tanto ao conteúdo quanto ao dispositivo. O CSS
tende a nos levar por este caminho, já que a maioria dos valores padrão foram
definidos com o intuito de deixar o conteúdo fluir. Novas técnicas de layout
como Flexbox e Grid CSS também têm valores padrão onde o conteúdo é uma parte
bastante importante nas definições de posicionamento e espaçamento.

Pode ser um pouco assustador não ter o controle total de como um componente ou
toda a sua interface de usuário aparecerá para o usuário final. Ao usar algumas
regras como `overflow-wrap: break-word` e `min-width: 200px` definimos limites
de como o conteúdo vai fluir dentro dos nossos componentes, tendo um pouco mais
de controle, mas não o suficiente para limitar demais o conteúdo.

![imagem de uma figura com sua descrição completa](/posts/tres-habitos-css-escalavel/chicago-fluida.png)

É claro que você pode misturar a abordagem fluída com a controlada. Esta
é normalmente a forma que eu implemento componentes que recebem conteúdo
bastante diverso. Você pode precisar controlar o tamanho do título
e a quantidade máxima de palavras na descrição de uma imagem, guiando quem
escreve o conteúdo a se encaixar em um meio-termo entre liberdade e controle.

## Desenvolva os seus hábitos

Não é fácil desenvolver interfaces para a web, principalmente para produtos que
evoluem em um ritmo constante. Escrever sobre estes três hábitos é o resultado
de muitos anos trabalhando em diversos projetos dos mais variados tamanhos. Com
certeza existem muitos outros hábitos que podemos seguir para escrever CSS
escalável, talvez alguns que eu até siga sem mesmo perceber ou formalizar.

Documentar problemas e soluções encontradas pode ser um ótimo caminho para você
começar a descobrir os seus próprios hábitos. Lembre de utilizar cada uma das
360 propriedades do CSS com uma coisa em mente: nunca faltarão tarefas para
alterar interfaces de usuário. Abrir mão do posicionamento, abrir mão do
tamanho e deixar o conteúdo fluir são só algumas boas práticas que podemos
seguir para manter nossos projetos em ordem mesmo após anos de trabalho.

[container-queries]: https://alistapart.com/article/container-queries-once-more-unto-the-breach/
[slides]: https://speakerdeck.com/hugobessaa/tres-habitos-para-escrever-css-escalavel


O que você precisa saber para escrever CSS que escala junto com o seu projeto.

Alcance o próximo nível em desenvolvimento front-end

Blog

O que é a Jamstack? Guia completo para iniciantes

3 hábitos para escrever CSS escalável

Guia de Estudos CSS