Não perca a cabeça: avaliando o Headless

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!

Com muitas opções vêm muitas decisões, e é fácil se afogar em todos os muitos e vários benefícios declarados dos diferentes sistemas. Então, como você aborda a avaliação dessas opções? Duas semanas atrás, Aaron Hans lançou luz sobre os casos de uso de ficar sem cabeça e o que é bom aqui na Smashing Magazine. Hoje, darei a você uma pequena introdução sobre o cenário do CMS, bem como algumas perguntas a serem feitas para ajudá-lo a tomar uma decisão.

Sem cabeça? Que?

O gerenciamento de conteúdo sem cabeça é a prática de dissociar seu sistema de gerenciamento de conteúdo (CMS) do seu front-end. Ao contrário dos sistemas tradicionais (ou “monólitos”), o CMS não é diretamente responsável por alimentar o front-end da web. Em vez disso, o conteúdo é servido para o front-end a partir de um sistema remoto por meio de uma API, e o front-end consome esses dados para renderizar suas páginas. Isso pode ocorrer em tempo de execução (quando um usuário acessa seu site) ou em tempo de construção (o conteúdo é pré-renderizado e gerado antecipadamente), mas o conceito importante aqui é a separação entre as camadas de conteúdo e apresentação.

Se você está planejando criar um site usando o Jamstack, vai acabar indo nessa direção por padrão, mas a abordagem é igualmente válida para outros tipos de projetos, usando linguagens do lado do servidor, como PHP, . Net ou Ruby.

Mas por que isso é mesmo uma coisa?

Headless surgiu originalmente como uma maneira de gerenciar conteúdo para o Jamstack (antes do Jamstack ter seu nome elegante), mas a abordagem conquistou fãs por vários motivos. O gerenciamento de conteúdo sem cabeça nos permite implantar conteúdo em diferentes plataformas, para que você possa usar o conteúdo do seu site em um aplicativo móvel nativo, por exemplo.

O Headless também nos permite corrigir falhas em outros sistemas. Por exemplo, Shopify. Embora seja ótimo no que faz, não é o sistema mais flexível quando se trata de gerenciar conteúdo para sua loja online. Usando um CMS headless, podemos gerenciar remotamente conteúdo adicional para um site da Shopify e trazer mais poder e flexibilidade do que teríamos por padrão.

Recentemente, trabalhei em um projeto fazendo exatamente isso - estendendo o conteúdo que Shopify fornece com conteúdo adicional e mais rico de um CMS headless (por acaso usamos o Contentful para esse projeto específico, mas qualquer CMS headless poderia fazer esse trabalho). O uso de uma solução de gerenciamento de conteúdo headless nos permitiu criar estruturas de dados personalizadas que poderíamos adaptar às nossas necessidades. Por exemplo, o cliente queria destacar os ingredientes usados ​​na fabricação de seus produtos, e Shopify realmente não fornece uma boa maneira de gerenciar isso. Criamos um novo tipo de conteúdo na Shopify e permitimos que ele fosse adicionado a uma página de produto personalizada repleta de outros tipos de conteúdo que criamos.

O conteúdo do Shopify foi obtido e sincronizado com o Contentful, e isso se tornou o principal driver de dados do site, com as APIs do Shopify realmente envolvidas apenas para verificações de nível de estoque e criação de cestas. Ser capaz de adicionar esse tipo de dados ricos a um site de comércio eletrônico baseado em SaaS foi incrivelmente poderoso.

Conseguimos esse resultado usando o Nuxt para construir o site, mas também poderíamos ter escolhido integrar os dados do CMS diretamente nos templates da Shopify. O Jamstack foi escolhido como a melhor abordagem aqui, mas o headless é flexível o suficiente para ser usado em praticamente qualquer lugar. Contanto que você tenha acesso a algum tipo de script por meio de JavaScript ou uma linguagem de back-end mais tradicional, como PHP ou .Net, você pode integrar o headless ao seu fluxo de trabalho.

Desacoplar seu conteúdo da sua camada de apresentação pode ser realmente poderoso. Permitir que seu conteúdo seja conectado a diferentes plataformas e camadas de apresentação ajuda a manter seu conteúdo consistente em seus pontos de contato e ajuda a garantir que seu conteúdo não seja fragmentado em vários sistemas diferentes gerenciados por equipes diferentes.

Imagine que você tem um produto sobre o qual deseja falar em seu site, em um aplicativo para celular e também em anúncios programáticos. Com o headless, você pode ter um repositório de conteúdo central e implantar o mesmo conteúdo (ou aspectos dele) em todas essas plataformas e muito mais. Com o gerenciamento de conteúdo mais tradicional, você precisaria gerenciar o conteúdo para diferentes plataformas separadamente.

Isso parece ótimo! Então, sem cabeça é certo para mim?

Há um monte de coisas a considerar ao escolher sua abordagem. Há benefícios em ficar sem cabeça, mas também há custos. Aqui estão algumas perguntas a serem feitas ao considerar o headless como uma abordagem:

Você está confortável com os requisitos de conhecimento para fazer a separação?

Muitas pessoas pensam que mudar para headless pode “se livrar” da necessidade de desenvolvedores de back-end, mas a verdade é que a mentalidade de estruturar dados de forma eficaz e construir modelos de conteúdo que funcionem e escalem bem ainda é muito diferente da mentalidade precisava ser um ótimo desenvolvedor front-end na maior parte do tempo. Ainda existe uma lacuna de conhecimento e que ainda precisa ser preenchida.

Se você estiver lidando com um projeto de escala significativa, provavelmente ainda desejará que alguns desenvolvedores se concentrem nas áreas de “back-end” e alguns se concentrem no “front-end”. As divisões são mais finas e maleáveis ​​em terras sem cabeça, mas não trabalhe sob a falsa suposição de que você pode reduzir pela metade sua força de trabalho de desenvolvimento apenas ficando sem cabeça.

Você sabe o custo total de propriedade?

Embora o headless possa muitas vezes ser mais barato do que um monólito, a natureza SaaS da maioria desses sistemas pode significar que, para conjuntos de dados grandes e que mudam rapidamente ou equipes muito grandes, os custos podem não aumentar. Sempre verifique como os custos são dimensionados e em que se baseia esse dimensionamento. Alguns fornecedores dimensionam com base no volume de dados , alguns no número de solicitações de API e alguns no número de colaboradores que editam seu conteúdo. A combinação destes pode ter um efeito dramático em como seus custos crescem com escala.

Você provavelmente também precisará analisar várias plataformas diferentes para formular uma ideia do seu custo total de propriedade. Se você não estiver obtendo a pesquisa “pronta para uso”, precisará considerar quanto custará adicionar esse recurso. Geralmente, você pode prever como esses custos serão dimensionados e, muitas vezes, pode começar pequeno, mas vale a pena estar ciente do que essas coisas podem custar a longo prazo.

Fique de olho também nos minutos de compilação se você optar por ficar sem cabeça: eles podem aumentar rapidamente, especialmente nas fases de desenvolvimento e preenchimento de conteúdo. Esteja ciente de que, se você optar por gerar seu site estaticamente, precisará de uma compilação após cada ação de publicação do CMS. Com sites grandes, essas compilações podem demorar um pouco, então vale a pena ter em mente que elas precisarão ser mantidas sob controle. Muitos dos serviços de hospedagem estática populares (como Netlify e Vercel) suportam o cache de ativos de compilação e, em combinação com estruturas modernas que permitem compilações incrementais, isso pode ajudar a mitigar esse custo crescente, mas você ainda precisa ficar de olho nele e fazer o seu pesquisa para garantir que você não seja pego.

Você explicou bem o suficiente para o seu cliente?

Você pode adorar a experiência do desenvolvedor de trabalhar com o Jamstack e sem cabeça, mas ao fazer essas avaliações, você deve ter em mente que os clientes são aqueles que precisam usar e conviver com as soluções que você criou, então você vai querer tentar tornar a vida deles o mais fácil possível.

Em uma função anterior, estive envolvido em uma proposta para um fabricante de automóveis que disse que queria o desempenho líder do setor como prioridade máxima, mas acabou optando por outra agência que oferece uma solução mais tradicional. Isso pode acontecer por vários motivos. (Provavelmente não fizemos um trabalho bom o suficiente para vender os benefícios de nossa abordagem, mas ficar sem cabeça também pode parecer bastante assustador para editores de conteúdo, especialmente quando confrontados com alguns dos sistemas tradicionais de “empresas” que têm talento para fazendo parecer que tudo “simplesmente funciona”.)

Quando você fica sem cabeça, você estará reunindo ferramentas individuais que são projetadas para serem muito boas em uma coisa específica, em vez de ter um grande sistema que pode fazer todas essas coisas em um só lugar. Isso pode ser bastante intimidante de lidar, a menos que você possa facilitar o máximo possível para o seu cliente lidar com isso.

Você está levando em consideração o tempo de desenvolvimento adicional?

Todo o poder potencial e flexibilidade do headless não vem de graça. Uma das desvantagens de tudo ser customizado é que isso significa que tudo precisa ser desenvolvido do zero . Com muitas das opções neste espaço, não há um esquema de documento “padrão” real - na verdade, eles são configurados de forma muito deliberada para não ter nenhum padrão como esse. Isso é ótimo, por um lado, porque significa que você obtém modelos de documentos bem adaptados que atendem precisamente às suas necessidades.

Por outro lado, porém, isso significa que alguém precisa definir esses modelos de documentos e, então, alguém precisa criá-los para o sistema que você está usando. Então, como o frontend e o backend são desacoplados, alguém normalmente precisará criar um mecanismo para permitir a visualização do conteúdo de rascunho ; muitas estruturas modernas incluem um sistema para permitir a visualização do conteúdo de rascunho, mas universalmente exigem configuração adicional para funcionar, e algumas exigirão um nível de código personalizado. Obviamente, o front-end não está vinculado ao conteúdo, portanto, qualquer mapeamento de dados para componentes de front-end também precisa ser feito. Você normalmente terá que fazer pelo menos um pouco disso mesmo com um CMS fortemente acoplado, mas o fato de que você provavelmente terá que alocar tempo para todas essas coisas pode ser caro.

Você/seu cliente está confortável com dados que não vivem em sua própria infraestrutura?

Embora muitos que trabalham com sistemas CMS headless e outros fornecedores de SaaS frequentemente considerem isso positivo, há situações em que seus dados fora de sua própria infraestrutura podem ser menos do que desejáveis, por exemplo, quando produtos confidenciais ou dados de produção não públicos estão envolvidos. A segurança para essas empresas geralmente é muito boa, mas sempre há riscos.

Certifique-se de avaliar os benefícios relativos de ter seu conteúdo hospedado em um servidor anônimo da AWS em algum lugar. Já vimos antes que mesmo a poderosa AWS pode ter interrupções e, para sistemas críticos para os negócios, isso pode ser extremamente caro. A diferença aqui entre o SaaS na AWS ou o uso de sua própria infraestrutura é que, se você tiver uma interrupção ou violação de segurança em sua própria infraestrutura, isso provavelmente se deve ao seu próprio produto ou código, mas em um ambiente SaaS/AWS, as interrupções são mais provável de ser causado por fatores não relacionados ao seu negócio. Esses casos são raros, mas acontecem e é importante que isso seja levado em consideração ao tomar essas decisões.

OK ótimo. Então, quais são minhas opções?

O número de soluções de gerenciamento de conteúdo headless e headless disponíveis em 2021 é impressionante e cresce constantemente. Em vez de tentar cobrir todas as opções aqui, quero dar apenas uma breve introdução a algumas das opções mais conhecidas. Se você estiver procurando por uma lista mais abrangente, confira o Headless CMS ou CMS Comparison.

Conteúdo

Contentful é uma das opções de CMS headless mais estabelecidas, tendo sido fundada em 2016 e tendo desfrutado de várias rodadas de investimento de sementes bem-sucedidas, e se descreve como “uma plataforma de conteúdo API-first para fornecer experiências digitais”.

A Contentful fez grandes avanços nos últimos anos para oferecer melhor suporte ao conteúdo traduzido e transcriado, e eles têm um bom suporte para vários “ambientes” de conteúdo, permitindo que alterações sejam feitas fora de seus dados de produção e migradas posteriormente.

Contentful tem um conjunto de integrações com outros aplicativos SaaS, por isso é fácil de integrar com Shopify ou CommerceLayer para comércio eletrônico ou Cloudinary para hospedagem e processamento de ativos.

Melhor para:

Aqueles que procuram a solução mais bem estabelecida no espaço sem cabeça.

Bloco de histórias

O Storyblok é a única das opções sem cabeça aqui que realmente se descreve como um CMS e apresenta um editor de conteúdo visual muito bom que permite criar e editar seu conteúdo aparentemente in-situ com uma maravilhosa interface WYSIWYG. Essa é uma das fraquezas tradicionais de separar o CMS do site, então ver esse tipo de ambiente de edição sendo criado pelo Storyblok é um grande passo à frente e a equipe deve se orgulhar de impulsionar o mercado nesse sentido.

O Storyblok também tem a capacidade de usar sua API para gerar esquemas de conteúdo que permitem que essas coisas vivam como e com seu código, o que é ótimo para manutenção. Permissões baseadas em função e recursos de tradução/transcriação tornam as equipes distribuídas trabalhando em sites multilíngues felizes. No geral, o Storyblok parece uma oferta extremamente polida e bem pensada, e que as equipes de conteúdo, em particular, provavelmente serão fãs.

Melhor para:

Aqueles que procuram a melhor solução de edição de conteúdo WYSIWYG da categoria a partir de um CMS headless.

Sanidade

Sanity é uma das crianças mais novas do quarteirão neste espaço, mas vem ganhando atenção rapidamente. Eles se descrevem como “a plataforma de conteúdo definitiva que ajuda as equipes a sonhar grande e entregar rapidamente”.

O Sanity faz as coisas um pouco diferente das outras opções aqui, pois todas as suas configurações e modelos de conteúdo são feitos como código, o que, para os desenvolvedores, é um lugar confortável para guardar as coisas. Ao permitir uma quantidade quase ilimitada de criatividade com modelos de documentos e tipos de campos personalizados, o Sanity permite que os desenvolvedores criem estruturas de conteúdo ricas e profundas para todos os tipos de coisas - não apenas conteúdo da web.

A suíte de edição do Sanity é limpa e simples, personalizável, de código aberto e é baseada no React. Você pode implantar o estúdio de edição em qualquer host que desejar ou optar por usar um subdomínio Sanity para hospedar em sua infraestrutura.

Melhor para:

Aqueles que precisam de controle absoluto sobre quase todos os aspectos da implementação, desde estruturas de dados personalizadas até componentes de entrada.

Prismico

Prismic realmente é o personagem antigo na sala no espaço sem cabeça, estando por aí em 2013, mas isso não os impediu de inovar no espaço. No ano passado, eles introduziram o SliceMachine, que visa preencher a lacuna entre desenvolvedores front-end que criam componentes e autores de conteúdo, criando uma relação 1:1 entre blocos de conteúdo (ou “fatias”) e componentes front-end, o que torna a construção de novos páginas e seções de conteúdo são uma brisa para os editores.

A suíte de edição da Prismic é adorável e parece que eles corrigiram alguns buracos que costumavam existir em sua seleção de campo, por isso oferece uma experiência completa.

Melhor para:

Aqueles que procuram minimizar o atrito para os editores de conteúdo.

E se eu quiser algo um pouco mais tradicional?

Wordpress

O Wordpress ainda é enorme em 2021. Apesar de todo o hype em torno de outras plataformas, o WordPress ainda alimenta cerca de 40% da Internet e não vai a lugar nenhum. Os desenvolvedores estão ajudando a garantir isso, melhorando seus recursos headless e concentrando-se mais fortemente em seu suporte à API. Novas ferramentas de edição também tornam a experiência de escrever no WordPress mais agradável, e algumas das vantagens inerentes ao trabalho com o WordPress foram muito melhoradas nos últimos anos.

Trabalhar com uma empresa de WordPress como serviço como a Nestify tira muito da ansiedade e dores de cabeça da segurança de suas mãos como desenvolvedor, mas esteja ciente de que, como a maior plataforma da internet, o WordPress ainda apresenta um alvo para aqueles com intenções maliciosas.

Melhor para:

Aqueles que procuram manter uma plataforma de conteúdo confortável e familiar, enquanto atualizam a tecnologia.

Sitecore

Como um dos gigantes do gerenciamento de conteúdo corporativo, Sitecore é talvez um dos nomes que você menos esperaria ver nesta lista, mas eles fizeram grandes avanços no suporte headless, liberando o Sitecore JSS para permitir que os projetos Jamstack interajam com os dados do Sitecore.

A grande dificuldade em trabalhar com Sitecore ou outros sistemas CMS corporativos de maneira descentralizada sempre foi colocar a personalização em funcionamento, mas esse problema foi resolvido pelo pessoal da Uniform, que realmente começou a trabalhar com o Sitecore para habilitar esse tipo de funcionalidade .

O Sitecore é uma grande fera e não será adequado para muitos projetos - o custo por si só o coloca fora do alcance de todos, exceto clientes de nível empresarial - mas vale a pena listar aqui, junto com o AEM, porque ainda há muitas pessoas que pensam que o gerenciamento de conteúdo sem cabeça é apenas para sites pequenos.

Melhor para:

Aqueles que estão olhando para um projeto corporativo com um cliente que não quer necessariamente entrar “tudo” em novas tecnologias.

Gerenciador de experiência da Adobe

O Adobe Experience Manager (ou AEM) é outro dos principais players do setor empresarial. É enorme e extremamente caro, assim como a maioria de seus concorrentes, mas a Adobe é outro fornecedor que fez grandes esforços para tornar sua oferta mais amigável para aqueles que desejam separar seu conteúdo da apresentação de seu site.

O AEM agora oferece suporte a alguns métodos diferentes de solicitação de dados de sua plataforma e a Adobe agora comercializa o AEM como um “CMS híbrido”, o que significa que ele combina operação headless e mais tradicional, específica de canal, sob um único capô. Isso pode ser uma grande vantagem para as equipes de marketing que precisam trabalhar em diversas plataformas e precisam de controle refinado do conteúdo entre essas plataformas, mas aqueles que desejam ter uma “plataforma única para governar todas” da Adobe precisarão de bolsos profundos para começar.

Melhor para:

Aqueles que olham para o topo de uma empresa, com bolsos fundos! O AEM faz muito (mais do que poderíamos mencionar aqui), mas é caro.

Agora tenho uma ideia das minhas opções, mas como posso ter a esperança de escolher entre elas?

Existem tantas opções no espaço sem cabeça agora, você pode facilmente acabar em paralisia de opções. Existem, no entanto, algumas perguntas que você pode usar para ajudar a formar uma opinião inicial ou pelo menos diminuir o campo:

Quanto tempo você levará para acelerar?

Diferentes sistemas têm diferentes curvas de aprendizado e diferentes maneiras de apoiar os desenvolvedores. Cada sistema listado aqui tem uma comunidade de desenvolvedores construída em torno dele, mas nem todas as comunidades são criadas iguais. O fornecedor fornece documentação detalhada? Projetos iniciais? Tudo isso pode ter um grande impacto no tempo de rotação.

Que tipo de modelo de suporte você precisará?

Os modelos de suporte geralmente são mais importantes para os clientes, e muitas vezes você descobre que, para acessar as linhas de suporte mais diretas, precisa pagar pelos pacotes “empresariais”, o que pode tornar seu investimento maior do que o esperado, considerando seu uso.

Quão bem estabelecido é o fornecedor?

Quão bem estabelecido é o fornecedor? Como são financiados? Novamente, essas são geralmente considerações do cliente e não do desenvolvedor, mas vale a pena ser capaz de dizer ao cliente desde o início que o fornecedor que você está recomendando é estável, existe há X anos e que eles têm apoio financeiro suficiente para tenha certeza de que eles não vão a lugar nenhum tão cedo. A última coisa que qualquer cliente quer ter que lidar é uma re-plataforma forçada porque seu fornecedor existente está desativando seu produto enquanto o cliente está no meio de seu engajamento!

Como é a experiência de edição?

A experiência de edição provavelmente será extremamente importante para várias pessoas no lado do cliente de qualquer projeto. Estas são as pessoas que trabalharão com qualquer CMS que você escolher dia após dia . Se o CMS for um pesadelo para usar, eles dirão isso – muito. Confie em mim, eu estive em muitos pitches e reuniões de acompanhamento onde uma quantidade significativa de tempo foi gasto com o cliente listando as muitas frustrações que eles têm com o sistema existente!

“Os sistemas que você está analisando podem fornecer edição no contexto ou visualizações de rascunhos ao vivo?”

“Quanto esforço é para configurar isso?”

“Quão rápido ou lento o próprio editor é executado?”

“O usuário é bombardeado com opções e botões desconhecidos ou as coisas estão bem organizadas?”

Todas essas perguntas contribuem para a facilidade geral de uso do sistema. Algumas soluções, como o Storyblok, fizeram um grande esforço para tornar a edição de conteúdo uma experiência rica e perfeita , mas geralmente não é considerado um ponto forte no cenário sem cabeça como um todo, então definitivamente vale a pena colocar uma demonstração em pequena escala na frente de seus editores de conteúdo e ver como eles se sentem sobre a(s) solução(ões) que você está de olho.

Quão fácil é tirar seus dados da plataforma?

Perdi a conta do número de reuniões de apresentação em que participei e me disseram que provavelmente teremos que começar do zero ou escrever um scraper personalizado para o conteúdo, porque o conteúdo do cliente está completamente vinculado a um sistema de gerenciamento de conteúdo proprietário, e eles não podem exportar seus dados facilmente.

Não importa o quão legal seu CMS de escolha pareça, tenha certeza absoluta de que existe uma maneira fácil de tirar todo o seu conteúdo do sistema em algum momento. Infelizmente, nenhum sistema é para sempre, e o cliente eventualmente vai querer mudar seu site e sua infraestrutura com ele. Qualquer coisa que você possa fazer para tornar a vida mais fácil para eles nesse momento será um enorme positivo.

Isso geralmente é mais fácil com soluções de CMS headless porque elas são compatíveis com API em seu núcleo, mas ainda é necessário um exame mais minucioso para garantir que você não cause uma grande dor de cabeça daqui a alguns anos.

Resumindo

Escolher uma abordagem e uma plataforma para o gerenciamento de conteúdo é uma grande escolha em qualquer projeto digital. O gerenciamento de conteúdo sem cabeça é poderoso e flexível, mas tem alguns custos e não é ideal para todas as situações.

Esteja ciente de que o preço que você vê antecipadamente do fornecedor raramente é o custo final e total da solução, e certifique-se de não cair na armadilha de pensar que pode reduzir os custos de desenvolvimento removendo os tradicionais -end” desenvolvedores.

Certifique-se de que todos estejam confortáveis ​​com as realidades de trabalhar com um CMS headless em vez de uma configuração mais tradicional, e certifique-se de trazer editores de conteúdo para a jornada, pois eles são as pessoas que trabalharão com o sistema que você mais configurou freqüentemente.

Espero que este guia tenha pelo menos ajudado a dar algum contexto ao hype e possa ajudá-lo a tomar uma decisão com a qual você e seu cliente possam se sentir confortáveis. Você pode construir praticamente qualquer coisa que quiser com o headless no centro agora – mas sempre pergunte a si mesmo se está buscando uma solução porque é familiar ou sensacionalista, ou se realmente é a melhor solução para suas circunstâncias.