As vantagens de um CMS headless: flexibilidade e escalabilidade em análise
Compreenda um CMS headless através de uma palestra publicada num site e numa aplicação: o que a separação permite, de que precisam os editores e como testar todo o processo.
Um conjunto de conteúdos, diferentes apresentações. Cada site ou aplicação continua a precisar de ser desenvolvido e ligado ao sistema.
Imagine que vai publicar uma palestra. O título, a fotografia, a descrição e a hora de início têm de aparecer no seu site e numa aplicação móvel. Se a hora mudar, quer corrigi-la uma única vez. Também quer que o site tenha o aspeto de um site e que a aplicação proporcione a experiência própria de uma aplicação.
Um sistema de gestão de conteúdos headless separa estas duas tarefas: manter a informação organizada e decidir como os leitores a veem. Essa separação pode ser útil. A vantagem depende do que precisa de publicar e de quem irá criar e manter as ligações.
O que significa, afinal, «headless»?
Um CMS é o espaço onde um editor escreve, organiza e publica conteúdos. Numa configuração convencional, também fornece os modelos que transformam esses conteúdos em páginas web. Um CMS headless deixa a apresentação a cargo de um site, de uma aplicação ou de outra interface separada.
As duas partes comunicam através de uma API: uma forma acordada de um programa pedir informação a outro. O site pode pedir o título, a hora e a fotografia da palestra e depois integrá-los na sua própria disposição de página. A aplicação pode pedir a mesma informação e organizá-la de outra forma.
O Strapi é um exemplo. Fornece uma interface de edição, modelos de conteúdo e APIs para utilização pelas aplicações. A API dá aos programadores acesso aos conteúdos; não concebe por eles a experiência do leitor.
Quando a flexibilidade se torna útil
Um mesmo conteúdo pode ser usado em vários locais. A hora da palestra pode ficar num único campo, em vez de ser copiada para várias páginas mantidas de forma independente. Cada aplicação continua a precisar de uma ligação funcional e de uma forma de receber as alterações. Uma página antiga guardada em cache pode continuar desatualizada até ser atualizada.
Um novo design não tem de implicar reescrever todos os artigos. Se os títulos, parágrafos, imagens e legendas forem guardados independentemente de uma disposição de página específica, uma nova interface de apresentação pode reutilizá-los. Isto funciona melhor quando o modelo de conteúdo descreve o material com clareza, em vez de guardar um único bloco extenso de código de marcação associado a uma disposição específica.
Diferentes leitores podem receber diferentes apresentações. Um ecrã de telemóvel, um artigo longo e um painel informativo num evento têm necessidades diferentes. A mesma informação de base pode servir os três, sem os obrigar a seguir o mesmo modelo.
O que a arquitetura não faz por si
Headless não significa automaticamente rapidez. Uma página pode ser preparada antecipadamente e disponibilizada depressa, ou pode fazer uma sequência de pedidos lentos antes de mostrar seja o que for. As imagens, a cache, o alojamento e a forma como a interface de apresentação é construída continuam a determinar o resultado. Separar as partes dá à equipa opções sobre onde melhorar o desempenho e aumentar a capacidade; alguém tem de fazer essas escolhas e testá-las.
Os editores também precisam de mais do que uma caixa onde escrever. Precisam de pré-visualizar um rascunho, verificar ligações e imagens, publicar no idioma certo e recuperar uma versão anterior. Os programadores têm de ligar essas tarefas à nova interface de apresentação. Um sistema que parece elegante num diagrama de arquitetura pode, ainda assim, tornar a publicação quotidiana pouco prática.
A mesma distinção aplica-se ao controlo. Uma API não determina quem pode alterar as regras, se é possível exportar tudo ou se pode continuar a publicar caso um fornecedor deixe de lhe prestar serviço. Essas questões dependem do software, das condições de alojamento, das permissões e da possibilidade prática de passar para outro sistema.
Experimente uma tarefa de publicação completa
- Escolha um conteúdo representativo: por exemplo, uma palestra com fotografia, data, descrição e uma versão numa segunda língua.
- Peça à pessoa que o vai editar que crie um rascunho e pré-visualize as disposições reais do site e da aplicação.
- Publique-o, altere a hora e verifique quando é que a correção aparece em cada destino.
- Restaure a versão anterior. Exporte os conteúdos e os ficheiros multimédia e verifique depois o que seria necessário para os utilizar noutro sistema.
Este pequeno ensaio revela mais do que uma lista de funcionalidades. Mostra se a arquitetura dá à sua equipa uma liberdade útil e se o trabalho quotidiano é exequível.
Escolha em função de uma necessidade de publicação
Uma solução headless pode ser uma boa escolha quando várias aplicações precisam dos mesmos conteúdos estruturados ou quando a experiência do leitor exige um desenvolvimento à medida substancial. Para um site simples com um único destino de publicação, um sistema que reúna edição e apresentação pode exigir menos trabalho. Comece pelo trabalho a realizar e só depois escolha a arquitetura.
Para uma comparação mais abrangente, leia como escolher um CMS em função do esforço de publicação e da possibilidade de mudar de sistema.