🛂 English Version
Um CMS híbrido capacita os desenvolvedores a fornecer conteúdo em vários canais, ao mesmo tempo que oferece aos profissionais de marketing algumas das interfaces com as quais estão familiarizados. É o melhor dos dois mundos… … Mas ainda há um longo caminho a percorrer.
O que acontece quando você está naquele momento em que precisa gerir conteúdo para diversos sites, aplicativos e dispositivos inteligentes, mas seu CMS só dá conta do conteúdo padrão da web? 😒
Talvez você faça parte do número de empresas que não dispõe do conjunto de tecnologias necessárias para se envolver com seu público por meio dessa multiplicidade de canais.
Nesse caso, o quadro piora quando se está preso a um CMS tradicional (também conhecido como CMS monolítico), seriamente atrasado em termos de tecnologia. Ao mesmo tempo, há situações em que a melhor alternativa ainda é ficar com o tradicional.
Afinal, existe uma arquitetura de CMS que pode ser considerada a “ideal”?
Neste artigo vamos refletir sobre as vantagens e desvantagens dos CMSs tradicionais, desacoplados, headless e híbridos.
Mas, antes de tudo isso, vamos resumir o que é o que faz um CMS.
CMS vem de Content Management System (sistema de gerenciamento de conteúdo). Como o nome já diz, o CMS é o software responsável por gerenciar o conteúdo, o que inclui a sua criação, edição e organização.
De acordo com a App Developer Magazine, os CMSs tradicionais “foram amplamente percebidos como insuficientes para habilitar e alimentar totalmente as necessidades de transformação digital da empresa moderna”.
A explicação técnica para as suas limitações desses CMSs está no fato de o back-end (onde os dados são inseridos) ser hospedado junto com o front-end (onde os dados são apresentados). Isso é o que chamamos de arquitetura acoplada.
Ainda segundo a App Developer Magazine, os CMSs tradicionais (a exemplo do Wordpress) são populares até hoje, mas começaram a perder espaço há mais ou menos uma década, justamente quando “os consumidores começaram a adotar dispositivos inteligentes, que competiam com os sites tradicionais no que diz respeito à forma como o conteúdo era consumido”.
Já que os CMS tradicionais não eram capazes de oferecer a flexibilidade necessária para alcançar o público nesses novos canais, as empresas de conteúdo criaram essa demanda no mercado da tecnologia.
Antes desses dispositivos inteligentes, um CMS precisava dar conta da entrega de conteúdos basicamente para desktops, notebooks e, depois de um tempo, também para dispositivos móveis.
Até aí, os CMSs tradicionais eram o padrão. O fato de serem acoplados não era nenhum demérito. Enfim, davam conta do recado.
Mas o número cada vez maior de diferentes dispositivos trouxe um problema para ser resolvido: a necessidade de separar o conteúdo da camada de entrega, de modo que ele possa ser entregue em qualquer lugar.
Para alcançar essa versatilidade, é necessário que o CMS venha sem um sistema front-end, que predetermine a forma como o conteúdo é compartilhado com o usuário final. É preciso que ele não tenha uma “cabeça” (front-end) pré-definida.
Surge o Headless CMS
Uma vez que o headless CMS não impõe limites à camada de apresentação, os desenvolvedores podem entregar o mesmo conteúdo tanto para um telefone celular ou quiosques em uma loja quanto para um navegador da web ou aplicativo de smartphone.
Sem o front-end, os headless CMS acabam agindo como um repositório de conteúdo - armazenando-o em seu formato bruto -, sendo que a capacidade de entregar esse conteúdo a qualquer dispositivo no mercado é conquistada a partir da aliança com algumas APIs.
Na arquitetura headless, o back-end e o front-end são desacoplados. O CMS é unicamente responsável por armazenar e gerenciar o conteúdo, sem uma estrutura pré-determinada para apresentá-lo.
O conteúdo é modelado primeiro e depois ganha vida em canais diferentes, o que garante grande escalabilidade.
Enfim, a moral do headless CMS é que ele pode gerenciar o mesmo conteúdo para mais de uma aplicação (ou um site + uma aplicação). Ou seja, é perfeito para qualquer projeto que demande a entrega para uma variedade de aplicações, sites e dispositivos.
Em matéria de produtividade, a separação do conteúdo e da apresentação permite que produtores de conteúdo e desenvolvedores trabalhem de forma independente, o que acelera o tempo de lançamento das aplicações no mercado. Essa é a parte que o pessoal das vendas mais gosta. 😉
Diferença entre CMS desacoplado e headless
Todo CMS headless é, em essência, desacoplado, pois back-end e front-end estão separados, mas nem todo desacoplado é headless. Há uma categoria chamada simplesmente de** CMS desacoplado**.
Segundo o pessoal da dotcms, um CMS desacoplado é semelhante a um CMS headless no sentido de proporcionar mais flexibilidade no envio de conteúdo para vários front-ends.
Mas há uma diferença importante: ao contrário do headless, o CMS desacoplado fornece as ferramentas, templates e outras opções de renderização que uma organização precisará para construir um site (como recursos de visualização, por exemplo).
Portanto, um CMS desacoplado devolve algum poder às equipes editoriais, que desejam controlar como seu conteúdo aparece o máximo possível. Mas ainda está longe de se equiparar à usabilidade apresentada pelos CMSs tradicionais…
CMS headless = dependência de desenvolvedores
De acordo com Omayi Walker, engenheiro de software sênior da Brightspot, não há como implementar um CMS headless pelo lado do front-end sem a presença de desenvolvedores, uma vez que eles serão responsáveis pelas APIs e pela construção do front-end em quaisquer canais downstream necessários.
Segundo Walker, já no back-end, um bom CMS provavelmente oferecerá APIs para tipos de conteúdo editorial comuns prontos para uso, mas a se encerra por aí: qualquer lógica de negócios adicional ou customização também exigirá um desenvolvedor.
CMSs tradicionais e headless: o que há de melhor em cada um
Os CMSs tradicionais ainda ganham dos headless no aspecto da usabilidade. Um exemplo disso é a funcionalidade WYSIWYG (What You See Is What You Get - “o que você vê é o que você obtém”, em tradução literal): você edita o conteúdo direto na página e consegue visualizar o resultado, coisa que nenhum headless CMS conseguiu fazer até agora.
Em compensação, os headless CMSs estão vencendo a batalha com os tradicionais em outros 4 quesitos importantes:
escalabilidade
performance
segurança
liberdade para o pessoal de TI, que pode desenvolver seus aplicativos front-end no framework de sua preferência (React, Vue.js e Angular, por exemplo), no qual podem ser construídos sites tradicionais ou single-page applications (aplicativos de página única - SPAs).
Só que, com a inexistência de WYSIWYG, os headless CMS geram um problemão para os produtores de conteúdo e profissionais de marketing. No headless, isso é o que eles encontram pela frente:
No caso do headless CMS, cabe aos desenvolvedores front-end projetar e organizar o conteúdo para que seja exibido e transmitido corretamente em sites, aplicativos, dispositivos habilitados para voz e wearable technology (“dispositivos vestíveis”, em tradução livre).
A função do profissional de marketing neste processo de publicação é limitada, pois não há editor, visualizações ao vivo ou interfaces drag-and-drop. Para quem não entende de código, isso é como largar uma pessoa com os olhos vendados em um ambiente desconhecido.
**Nossa opinião sobre essa briga: **há prós e contras dos dois lados, a ponto de, dependendo da intenção do projeto, uma das abordagens ser totalmente inviável para sua execução.
Quer exemplos?
Se você precisa entregar o mesmo conteúdo para uma variedade de aplicações, sites e dispositivos, um headless CMS é a melhor opção.
Agora, se você não pode depender tanto dos desenvolvedores e, ao mesmo tempo, precisa dar autonomia para os produtores de conteúdo, o bom mesmo é se agarrar a um CMS tradicional.
Mas tem uma coisa: atualmente, o que o mercado está buscando, na verdade, é a junção das duas coisas - ou o melhor dois mundos.
*Fonte da imagem: core dna *
Um CMS híbrido é um CMS sem cabeça, desacoplado, mas também com um front-end. É um CMS monolítico tradicional, só que com uma API de “conteúdo como serviço” (Content as a Service - CaaS).
Embora desacoplado do back-end, um CMS híbrido inclui uma camada de apresentação semelhante a um CMS tradicional (ou acoplado) ao mesmo tempo, usando uma arquitetura headless para entrega do conteúdo.
O CMS híbrido é uma solução “intermediária”. Ele dá aos desenvolvedores um certo nível de liberdade (alimentada por APIs) para entregar conteúdo em vários canais, enquanto oferece aos profissionais de marketing algumas das interfaces que eles estão acostumados a partir do CMS tradicional para entrega de conteúdo aos canais da web.
Uma arquitetura de sistema híbrido pode tomar forma de algumas maneiras diferentes. Se você estiver executando vários sites, poderá adotar uma abordagem headless com alguns deles, mas especificar um front-end para outros. Ou talvez você mantenha um front-end para o seu site e, ao mesmo tempo, opte por ser headless nos aplicativos móveis, renderizando-os com sistemas downstream.
E este é o ponto: a decisão é sua. Tudo depende da sua equipe e das metas de negócios. Não é preciso adotar o headless puro e sentir falta dos recursos do tradicional, e vice-versa.
É o melhor de dois mundos, literalmente.
Vamos nos aprofundar um pouco mais no CMS híbrido, apresentando as vantagens elencadas pela Brightspot.
Vantagens da arquitetura do CMS híbrido
Um CMS híbrido tem as vantagens do desacoplado e headless, oferecendo aplicativo e plataforma.
Assim como o sistema headless, a arquitetura de sistema híbrido promove a reutilização de conteúdo.
Geralmente é baseado na nuvem ou pronto para a nuvem.
Você pode obter a funcionalidade WYSIWYG para autoria, gerenciamento de modelos, navegação em sites, gerenciamento de vários sites, acessibilidade, compliance, SEO, verificação de links, gerenciamento e administração de versões e workflow.
O sistema promove a colaboração entre o marketing e a equipe de desenvolvimento em uma gama completa de experiências digitais.
Conclusão
Apesar de levantarmos as bandeiras da Jamstack, serverless, edge computing e outras tecnologias de ponta no desenvolvimento da web, admitimos que, no quesito usabilidade, os headless CMSs deixam MUITO a desejar.
Exemplo:
Nossa equipe de conteúdo usou o CMS da Forestry por um tempo, que é headless. Acontece que realmente sentimos falta da usabilidade do bom e velho WordPress…
Acabamos nos rendendo. Tecnologicamente falando, pode-se dizer que demos um passo atrás ao voltar para o WP. Por outro lado, estamos mais satisfeitos com a produção de blog posts no sistema monolítico.
A princípio, a arquitetura híbrida veio para resolver essa situação. O que o mercado precisa na atualidade é de uma solução que contemple as necessidades dos desenvolvedores, dos produtores de conteúdo e das estratégias de business das empresas, tudo ao mesmo tempo.
Só que os CMSs híbridos ainda estão engatinhando. Nenhuma empresa conseguiu masterizar a construção de uma ferramenta nesses moldes. A avenida continua aberta.
Enquanto isso, fica a dica: identifique as suas prioridades e as compare com as características dos CMSs tradicionais e headless, enquanto a arquitetura híbrida ainda não está madura. Abrace o formato que contempla suas necessidades da melhor forma possível… e aguarde pela solução que, no nosso ponto de vista, será a ideal para praticamente qualquer tipo de empresa.
Melissa Webster, da International Data Corporation, concorda conosco:
“Acreditamos que a solução definitiva é realmente uma abordagem híbrida que traz todos os benefícios do gerenciamento de conteúdo da web que acumulamos nos últimos 25 anos e adiciona a capacidade de oferecer suporte aos desenvolvedores que criam aplicativos headless.”
Então, enquanto a arquitetura do CMS híbrido continua sendo aprimorada, a saída é saber escolher a melhor opção disponível.
E você? Como foram as suas experiências com CMSs até o momento? É super importante trocar figurinhas sobre tecnologias que estão em pleno desenvolvimento.
Quer agregar nesse debate? Deixe um comentário!
Se quiser ir além desse conteúdo e conversar sobre outras tecnologias, entre no nosso servidor no Discord. 😊
![O que é FinOps: como otimizar custos de cloud e infraestrutura digital [VERSÃO REDUZIDA]](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1689365697155%2Fdb41e005-1e30-47f3-a6e1-205399b02921.png&w=3840&q=75)
