Ficando sem cabeça: casos de uso e para que serve

Este artigo foi gentilmente apoiado por nossos queridos amigos do Storyblok, um CMS headless amigável com um editor visual, componentes aninhados e blocos de conteúdo personalizáveis ​​para sites e aplicativos. Obrigado!

Olhando para os anos de desenvolvimento para a web, usei dezenas de ferramentas CMS diferentes, tanto prontas quanto caseiras. Tenho implementado e construído muitos sites e plugins WordPress , bem como extensões para sites CMS de serviço completo em .NET. Mas para mim, tudo mudou quando ouvi falar de headless pela primeira vez e agora, anos depois, não poderia estar me sentindo mais confortável no ecossistema headless .

Esse entusiasmo não vem do nada. Embora possa parecer assustador entender todas as opções sem cabeça, tenho refinado minha própria estratégia para diferentes opções sem cabeça em diferentes ambientes e me familiarizei com os suspeitos usuais no espaço sem cabeça. Mudar para o headless me ajudou a evitar obstáculos causados ​​por limitações de sistemas multifuncionais maiores.

A funcionalidade compartimentada para que você possa atingir metas complexas hoje e preparar seu aplicativo para evoluir facilmente no futuro me traz tranquilidade. Tem sido um prazer contribuir para implantações e iterações bem-sucedidas em serviços da Web construídos em soluções headless para empresas privadas e o governo do estado da Califórnia.

Neste artigo, eu adoraria compartilhar algumas dicas e diretrizes úteis que aprendi ao longo desses anos, com a esperança de que eles ajudem você a entender o mundo sem cabeça e a encontrar os candidatos certos para seus projetos. Mas antes de mergulharmos, precisamos voltar um pouco no tempo para entender o que o headless traz para a mesa.

Antes sem cabeça

Apenas alguns anos atrás, nossos fluxos de trabalho pareciam estar se concentrando em uma variedade de ferramentas, pilhas e tecnologias. Para CMS, estávamos usando principalmente ferramentas tudo-em-um. Eles incluíam as funções de criação de conteúdo e visualização de conteúdo.

Os usuários dessas ferramentas ficaram presos ao front-end que acompanhava o back-end. Sua capacidade de personalizar as coisas era limitada. Você pode instalar plugins, mas todos eles precisam ser construídos para sua ferramenta. Você pode escrever código personalizado — mas apenas na linguagem em que sua ferramenta foi construída e dentro de suas restrições.

Tudo mudou nos últimos anos com o CMS headless ganhando força em todo o setor.

Um renascimento de ferramentas especializadas

Hoje, temos um florescimento de ferramentas especializadas em visualizações de criação ou apresentação de conteúdo. Um CMS headless se concentra na parte de autoria de conteúdo e fornece uma maneira de conectar uma ferramenta de apresentação de conteúdo separada. A falta de um frontend voltado para o usuário é o que o torna headless e oferece a flexibilidade de trabalhar com qualquer ferramenta por meio de sua API.

Ser capaz de projetar seu próprio frontend do zero é libertador para muitas equipes de desenvolvimento. Você pode ter uma equipe de engenheiros fluentes na entrega de aplicativos de página única em Vue.js ou renderização rápida, sites gerados estáticos à prova de balas com 11ty. Todas as estruturas de desenvolvimento web mais recentes são projetadas para funcionar facilmente com dados estruturados que podem ser fornecidos a partir de qualquer CMS headless.

Um CMS headless é uma ferramenta focada. Tem menos responsabilidade do que uma solução tudo-em-um. Os endpoints de API fornecidos por um CMS headless fornecem uma separação clara entre os sistemas para que você possa trocar as arquiteturas de front ou back-end independentemente à medida que as coisas evoluem. Seu produto cresce, o ecossistema de ferramentas se expande, novas abordagens se tornam disponíveis. Seus requisitos de back-end e front-end serão alterados. Se você tiver uma configuração sem cabeça, poderá se adaptar mais facilmente porque seu front-end e back-end já estão separados por uma API e você pode atualizá-los de forma independente.

Headless é certo para mim?

Mais notavelmente, o headless oferece a flexibilidade necessária para atender a requisitos desafiadores. Pode ser difícil atingir suas metas se você tiver que modificar muito um produto multifuncional. Combinar uma ferramenta sem cabeça com um frontend menor, diferente ou feito em casa pode ser a maneira mais fácil de fornecer os designs e fluxos de usuário desejados.

• Se você deseja ajustar cada etapa do fluxo de checkout do produto , pode usar uma opção de comércio sem periféricos para conseguir isso,
• Se você deseja otimizar fortemente o tempo até o primeiro byte , talvez queira usar um gerador de site estático que reconstrói o conteúdo na alteração com base em uma API CMS headless,
• Se você hospeda suas próprias ferramentas e é cauteloso com a segurança, você pode querer bloquear seu ambiente de autoria atrás do firewall e consumi-lo diretamente de um front-end baseado em Jamstack mais simples,
• Se você estiver servindo o mesmo conteúdo para uma variedade de clientes, como web, aplicativos nativos ou widgets de terceiros, você pode criá-los de forma que todos eles se comuniquem através do mesmo CMS sem controle.

Se você pode atender perfeitamente aos requisitos do seu projeto com uma ferramenta tudo-em-um, as opções sem cabeça provavelmente são um pouco exageradas para você. Da mesma forma, se sua equipe está perfeitamente satisfeita e bem versada com sua solução multifuncional atual, você não precisa se preocupar em dividir as ferramentas de front-end e back-end. No entanto, se, em vez disso, você estiver se deparando com as limitações de suas ferramentas, ficar sem cabeça permitirá que você resolva seus pontos problemáticos diretamente.

Exemplo: comércio eletrônico sem cabeça

Vejamos uma escolha headless específica: você pode integrar uma plataforma de comércio eletrônico existente, como Shopify, como um fluxo completo que assume todo o processo de checkout, ou você pode usar uma opção headless fornecida pela Shopify também.

• No primeiro caso, seu design dependerá muito dos modelos da Shopify e da funcionalidade pronta para uso , portanto, será possível ajustar o fluxo de checkout, mas bastante limitado.
• No último caso, você pode projetar seu fluxo de checkout da maneira que quiser e confiará no Shopify apenas para realizar a transação financeira.

A diferença significativa é que a opção headless exigirá que você construa todas as visualizações que seu usuário vê. Mais uma vez, se isso soa como um aborrecimento sem vantagens, você provavelmente não precisa de uma solução sem cabeça.

Uma equipe que precisa da versão sem cabeça receberá a liberdade que isso oferece. Seu design não terá restrições e você poderá controlar cada pixel de cada visualização. Você estará no controle total de todo o código executado nos dispositivos de seu usuário, para que possa rastrear, otimizar e acelerar literalmente cada interação.

Ao mesmo tempo, você ainda está deixando o processamento de transações para sua solução de comércio eletrônico sem cabeça, para obter os benefícios de seu sistema de back-end.

A conclusão é: se você está lutando com os gargalos em sua solução de comércio eletrônico atual - seja front-end pesado, interface de usuário complexa ou apenas design inacessível -, uma opção sem cabeça tornará mais fácil para sua equipe resolver esses problemas. Da mesma forma, se parecer que será mais fácil para sua equipe aumentar seu funil de conversão, tornando a implantação de novos recursos mais rápida e suave, é uma boa ideia considerar também a opção headless.

Evitando o aprisionamento com uma única plataforma

Olhando para o estado do front-end hoje, dissociar seus veículos de autoria e entrega de conteúdo é a maneira mais segura de arquitetar coisas em um mundo onde as opções de ferramentas de front-end e back-end estão em constante expansão. Não é incomum que os ambientes de autoria e leitura tenham diferentes conjuntos de requisitos, portanto, poder escolher ferramentas que os abordem separadamente oferece melhores opções para ambos os lados.

As configurações baseadas em Jamstack são habilitadas por APIs, portanto, geralmente estão vinculadas a um CMS headless. No entanto, fazer uma escolha sem cabeça não requer um front-end do Jamstack . Claro, você ainda pode executar algum código do lado do servidor, se quiser.

Por exemplo, ajudei a construir alguns sites executando Node.js e Express consumindo APIs de back-end como Wordnik.com e esse padrão popular funciona sem problemas. Ter acesso aos seus dados por meio de APIs possibilita descartar o código do lado do servidor em produção, para que você possa adotar facilmente abordagens do lado do cliente, como o Jamstack, se isso fizer sentido em seu projeto.

O problema com as soluções “tudo em um” é que cada uma delas tem muitos compromissos embutidos. Por exemplo, você deve se comprometer a oferecer suporte a um ambiente de banco de dados e programação ou escolher entre fornecedores de SaaS que o façam; além disso, suas alterações de design terão que ocorrer dentro dos temas e plugins disponíveis.

Com o headless, escapamos de ficar presos em uma única plataforma. Portanto, se você precisar usar uma nova estrutura de front-end para o seu site ou quiser remover a infraestrutura de produção cara e usar geradores de sites estáticos, ou talvez queira mudar seu CMS sem reconstruir todo o front-end do zero - em comparação com alternativas , você pode conseguir tudo isso com muito menos atrito quando estiver usando uma opção sem cabeça.

Vamos dar uma olhada em um exemplo simples. Imagine que sua organização tenha uma nova iniciativa e um novo design, e os fluxos sejam criados do zero para atender às novas necessidades dos usuários. De repente, uma nova pilha de tecnologia precisa ser montada para atender a esses requisitos.

Escolher uma opção headless dará aos seus produtos uma chance melhor de longevidade e tornará muito mais fácil permitir que seu conteúdo seja movido para vários canais de entrega sem problemas.

“

Nesses casos, você precisará procurar uma solução pronta para uso que corresponda perfeitamente às suas necessidades ou comprometer alguns dos requisitos de design e fluxo do usuário para que funcione bem o suficiente. Mas se seus requisitos de design ou desempenho forem rigorosos, pode ser mais fácil atingir essas metas sem cabeça.

A conclusão é que há muitos casos de uso ao escolher uma opção sem cabeça que dará aos seus produtos uma chance melhor de longevidade , além de tornar muito mais fácil permitir que seu conteúdo seja movido para vários canais de entrega sem problemas. Ser capaz de consumir seu conteúdo como dados estruturados permite que ele prospere em seu próprio site, em seus aplicativos nativos e seja distribuído para fontes externas.

Nem tudo precisa ser sem cabeça

Pode parecer que sem cabeça é sempre uma opção melhor, mas não é. Se em seu projeto atual você não está muito preocupado com o design e as opções técnicas descritas acima, ou você só precisa de um site operacional que faça o trabalho hoje, provavelmente não precisará tanto do headless.

É claro que a velocidade do conceito à entrega é importante, portanto, como você está a poucos cliques de um site de aparência decente sem suporte de engenharia adequado do seu lado, convém adiar as opções sem cabeça para mais tarde. Você pode se concentrar na otimização e longevidade do site quando sentir que sua ideia pode estar funcionando.

Como as escolhas sem cabeça ajudam você a se recuperar de erros

Atualizando o back-end

Perigos do preço por usuário

Há algum tempo, ajudei a montar um sistema de blogs que seria usado por dezenas de autores. Ficamos muito impressionados com o conjunto de recursos de um dos fornecedores de CMS headless, escolhemos-o para o CMS headless e gostamos de construir um frontend em cima dele que se fundiu suavemente em nosso conjunto de produtos. Eventualmente, a empresa decidiu que o número de autores deveria ser expandido para alguns milhares.

A maioria das soluções de CMS hospedadas não publica a estrutura de preços para números de usuários tão grandes. Quando perguntamos sobre o custo de continuar executando isso na mesma plataforma, não gostamos muito da resposta. Para que este sistema continuasse a fazer sentido para os negócios, tivemos que trocar nosso CMS. Conseguimos fazer a troca sem descartar o frontend também por causa da arquitetura sem cabeça.

Limitação da API

Muitas startups que se concentram exclusivamente no ambiente de autoria são capazes de criar belos produtos com APIs amigáveis ​​ao desenvolvedor. O Airtable é um exemplo de inovação em planilhas por meio de uma interface de usuário amigável combinada com uma experiência de desenvolvedor limpa por meio de uma API bem documentada.

Construí alguns protótipos úteis nos quais alimentei dados extraídos no Airtable, onde foram editados por especialistas humanos, depois usei suas APIs para alimentar visualizações de conteúdo em execução no site principal e em incorporações executadas em sites de terceiros. Ao configurar o sistema de leitura , puxei os dados do Airtable para um sistema pronto para produção que pudesse lidar com grandes cargas de tráfego e isso funcionou bem por um tempo.

Comecei a ter problemas com a gravação de dados. As chamadas estavam falhando devido ao limite rígido de 5 solicitações por segundo. Atingir esse limite fornece um bloqueio completo de solicitação de API de 30 segundos. Eu estava tentando enviar dados de um sistema distribuído, então adicionei aceleradores e divida as coisas em bases separadas.

À medida que o sistema se expandia e a quantidade de dados crescia, estávamos superando essa ferramenta. Consegui resolver isso criando recursos rudimentares de edição de dados em um sistema baseado na instância do AWS DynamoDB que estava lendo do airtable. Conseguimos trocar rapidamente os recursos de interface do usuário de criação do Airtable por uma escala maior e contas mensais de SaaS mais baixas.

Este é outro exemplo de como uma separação clara entre o front-end e o back-end fornecida pelas APIs das ferramentas de autoria headless permite direcionar os pontos problemáticos com precisão.

Atualizando o front-end

Novos frameworks brilhantes

As organizações que já existem há algum tempo geralmente têm o problema de precisar dar suporte a sistemas de produção construídos em uma variedade de pilhas de tecnologia . Há uma pressão constante para homogeneizar o ferramental, mas também para inovar. Eu fazia parte de uma equipe encarregada de criar visualizações e widgets que se integrassem a produtos existentes com base em um CMS headless. Nós nos divertimos muito construindo protótipos rapidamente com diferentes ferramentas de front-end leves.

Realizamos um concurso interno para ver qual engenheiro da equipe de front-end poderia criar o melhor front-end com base no conteúdo fornecido pelos endpoints da API CMS headless. Uma apresentação tinha o melhor conjunto de recursos e a menor pegada de código para que os desenvolvedores obtivessem o projeto e entregassem o produto construindo-o com o Riot.js.

Riot.js é uma pequena biblioteca legal que inclui vários recursos em um tamanho pequeno. Ele ajuda você a escrever componentes de arquivo único orientados a dados, como Vue.js. Quando o desenvolvedor deste frontend deixou a empresa logo após o lançamento da versão 1.0, a equipe perdeu a única pessoa com entusiasmo por essa biblioteca.

Às vezes, a queda de um padrão de desenvolvimento excitante, novo e rápido para a dívida tecnológica acontece rapidamente.

“

Felizmente, a natureza desacoplada da arquitetura CMS headless oferece a flexibilidade de alterar seu front-end sem tocar no back-end . Conseguimos reescrever o código de front-end e trocar componentes de front-end atualizados com base em diferentes bibliotecas que eram mais comumente usadas em outros projetos.

Velocidade bruta

Eu amo o projeto Fantasma. Eu fui um dos primeiros assinantes porque foi legal ver uma solução semelhante ao WordPress construída em Node.js. Eu respeito esta organização por oferecer um serviço baseado em ferramentas de código aberto que elas estão constantemente refinando. Fiquei muito feliz com esta ferramenta quando a usei para o meu blog pessoal.

Havia uma faceta da solução que não era perfeita. O tempo para o primeiro byte no meu blog hospedado pelo Ghost foi muito lento. Como eu poderia recuperar todo o conteúdo do post por meio de uma API, consegui configurar meu próprio frontend gerado estaticamente no S3 + Cloudfront que usava todo o conteúdo do post que eu havia escrito no Ghost, mas tinha um tempo mais rápido para o primeiro byte.

CMS sem cabeça como um serviço

Existem muitas empresas de Software As A Service que apostaram tudo no headless. A inscrição em um desses fornecedores pode fornecer imediatamente um ambiente de edição de conteúdo amigável e endpoints de API limpos para trabalhar. Aqui está uma rápida comparação de alguns deles, todos com planos básicos de custo muito baixo e um foco a laser na experiência de CMS sem cabeça.

Todos esses serviços possuem uma base sólida de recursos . Todos eles incluem hospedagem de ativos estáticos, histórico de revisões salvo e suporte de localização bem documentado. Eles diferem em sua interface de usuário de criação de conteúdo e recursos de API.

Emocionantes padrões sem cabeça

Usando um CMS baseado no GitHub

Poder tirar proveito do gerenciamento de usuários, controle de versão e fluxos de trabalho de aprovação no GitHub são grandes vantagens. É útil não ter que configurar novas contas em novos sistemas. Ser capaz de ver o histórico de comentários junto com as atualizações de conteúdo é bom.

Existem diferentes tipos de ferramentas CMS baseadas no GitHub. Esta tem sido uma maneira rápida de criar sites de documentação: Spacebook, você pode integrá-lo ao Netlify para obter uma interface de usuário de edição de markdown mais limpa ou usá-lo diretamente no GitHub.

Os recursos de visualização que agora estão integrados ao editor da Web do GitHub tornam algumas dessas ferramentas mais acessíveis para pessoas que não estão familiarizadas com HTML. Adoro a opção de comparação rica em visualizações, onde o GitHub mostra alterações de redução no modo de visualização completa.

Esta é uma excelente lista de 85 ferramentas CMS que permitem classificar se são baseadas no GitHub ou não.

APIs para ferramentas familiares

Sua instalação do WordPress vem com endpoints de API, para que você possa continuar usando as ferramentas de autoria que sua equipe tem experiência de forma descomplicada. O WordPress tem uma boa documentação para sua API REST. Isso é ativado em novas instalações do WordPress, portanto, quando você cria um novo ambiente de autoria do WordPress, pode começar a ler o JSON em https://example.com/wp-json/wp/v2/posts .

A página de configurações do WordPress contém um campo de serviço de atualização onde você pode inserir URLs para serviços que deseja que ele faça ping quando o conteúdo for alterado. Isso é perfeito para acionar uma ferramenta sem servidor para obter as atualizações mais recentes. WordPress v5 tem este campo na seção Writing das configurações

Combinando fontes de dados

O uso de ferramentas sem cabeça para o estado da Califórnia nos ajudou a criar sites de resposta a emergências que elevaram o nível de desempenho. Tínhamos controle total da arquitetura front-end e ainda podíamos permitir que os escritores usassem ferramentas de autoria familiares.

Usamos o WordPress sem cabeça , escrevendo para o GitHub via FAAS. Também estamos gravando outras fontes de dados no repositório e acionando compilações de gerador de site estático em cada alteração. Exemplos de dados que são gravados no git, além do conteúdo editorial original, são dados que mudam apenas uma vez por dia, como as estatísticas de primeira linha e nossas versões traduzidas por humanos de cada página.

O uso de ações do GitHub como gatilhos de compilação nos permitiu integrar várias fontes de dados diferentes ao site para obter uma publicação rápida e uma pequena área de infraestrutura de produção. Menos infraestrutura de produção nos permite respirar com facilidade quando atingimos grandes picos de tráfego relacionados a anúncios de pandemia do governo.

O repositório WordPress -> FAAS -> GitHub parte da arquitetura foi criado por Carter Medlin. Ele conectou esse pipeline do zero em alguns dias enquanto projetamos e construímos o front-end do site. Isso está sendo executado em uma função do MS Azure sem servidor, portanto, há baixos custos de infraestrutura e manutenção. Ele recebe pings do serviço de atualização do WordPress descrito anteriormente, extrai o json da API do WordPress e grava o novo conteúdo no GitHub. O código para este endpoint sem servidor pode ser visualizado no GitHub.

Os bots estão trabalhando duro para publicar todas as atualizações de conteúdo à medida que recebem pings do WordPress. Essa atividade cria um log facilmente revisável de cada atualização e a capacidade de reverter as alterações com os processos normais do GitHub.

Construir o frontend deste site usando o gerador de sites estáticos 11ty foi rápido, divertido e funcionou perfeitamente. Recebemos grandes picos de tráfego em notícias relacionadas à pandemia e saber que temos um front-end estático reduz o risco quando a contagem de usuários simultâneos começa a aumentar e estamos publicando muitas atualizações de conteúdo.

Eu gosto de como a comunidade 11ty se concentra em desempenho e acessibilidade com seus placares de líderes da comunidade e arquitetura leve. É importante garantir que as ferramentas criadas pelo estado funcionem para todos os californianos. Queremos que as coisas funcionem em qualquer dispositivo sob condições de baixa largura de banda e suporte a todas as tecnologias assistivas. É muito legal podermos usar ferramentas como o 11ty que facilitam a entrega de sites rápidos e acessíveis. Usamos componentes da Web no frontend para fornecer recursos adicionais, mantendo o peso do código pequeno.

Considerações ao fazer escolhas sem cabeça

Animado com os recursos que as ferramentas headless oferecem à sua equipe? O número de opções disponíveis pode ser esmagador. Esta é uma lista de recursos que podem ajudá-lo a reduzir as opções:

Recursos do ambiente de criação

• Facilidade de autoria de documentos
• Facilidade de adicionar dados estruturados
• Opções de layout
• Recursos de visualização
• Fluxos de trabalho de aprovação de conteúdo

Recursos da API de conteúdo

• Quais consultas estão disponíveis
• Quão granular é a estrutura de conteúdo
• Existem limitações no acesso a dados (limites rígidos da API REST Airtable)
• Escalabilidade : você precisa colocar um CDN na frente de sua API de conteúdo
• Facilidade de adicionar localização
• Divulgar seu conteúdo, e se você mudar seus planos, quão difícil será extrair todos os seus dados?

Custo

• Você está pagando por usuário por soluções hospedadas?
• Você está gerenciando software de código aberto instalado em seu próprio ambiente?
• As contas de usuário são fáceis de administrar?
• Você pode se integrar com suas soluções de logon único existentes?
• O produto passou nas auditorias de segurança, inclui autenticação de dois fatores ?

Fluxos de controle/aprovação de origem

• O conteúdo tem versão , para que você possa reverter para versões anteriores e acompanhar o que foi publicado e quais edições foram feitas quando?
• Você pode compartilhar novas versões de conteúdo antes de publicá-las? Você pode restringir o acesso a essas visualizações?

Gerenciamento de arquivos estáticos

• Quão fácil é para seus autores adicionar novas imagens, pdfs, etc.?
• Facilidade de vincular arquivos carregados pelo autor em fluxos de otimização de imagem?

Para onde o Headless está indo

Ao observar atentamente o cenário headless, você descobrirá que as ferramentas headless limitam intencionalmente seu escopo funcional e fornecem maneiras de integração em sistemas maiores. Desagregar recursos específicos é benéfico quando os sistemas se tornam mais complexos. É apenas mais fácil fazer escolhas específicas que limitam os requisitos de custo, segurança, manutenção e hospedagem de áreas de código maiores quando você trabalha com ferramentas menores e focadas.

Vale a pena notar que as opções headless geralmente exigem que você mesmo escreva algum código . No entanto, como os front-ends são cada vez mais um conjunto de componentes pré-construídos e muitas vezes um design completo preenchido com seus próprios dados, não deve ser muito presunçoso esperar mais maneiras de misturar e combinar ferramentas especializadas e integrar perfeitamente opções headless sem escrever código você mesmo.

O back-end perfeito para um projeto pode ser apenas uma assinatura SAAS ou uma instalação de projeto de código aberto. Isso pode se integrar sem código com um front-end pronto para uso que atenda a todas as suas necessidades. Vejo que o Stackbit já está fundindo o CMS headless com o frontend sem código. Posso configurar um novo site usando a ferramenta de criação de página de código sem WYSIWYG da Stackbit e, em seguida, posso escolher entre um conjunto de opções de CMS headless de diferentes fornecedores para gerenciar os dados completos do site.

Neste artigo, analisamos alguns casos de uso em que ficar sem cabeça ajudou as empresas para as quais trabalhei a lidar com as mudanças. Escolhas headless são atraentes se você estiver interessado nelas para flexibilidade de arquitetura de aplicativos, controle de experiência do usuário ou pensar cuidadosamente sobre a longevidade do seu serviço.

Estou animado para ver como esse espaço continua a crescer e continuarei procurando maneiras de usar essas opções para fornecer produtos melhores e facilitar meu trabalho como desenvolvedor.

Recursos adicionais

• Headless CMS, uma excelente lista de 85 ferramentas de CMS que permite classificar se são baseadas no GitHub ou não.
• “Como criar um site WordPress sem cabeça no Jamstack”, Sarah Drasner e Geoff Graham
• Comércio sem cabeça, Shopify
• “GoTrue JS: trazendo autenticação para sites estáticos com apenas 3kb de JS”, ​​Divya Sasidharan, Netlify
• A experiência de edição para sites Jamstack, Stackbit
• API de integração do Wordpress, CAdotGov, GitHub

Este artigo foi gentilmente apoiado por nossos queridos amigos do Storyblok, um CMS headless amigável com um editor visual, componentes aninhados e blocos de conteúdo personalizáveis ​​para sites e aplicativos. Obrigado!