Introdução ao AEM Headless getting-started

Nesta parte da Jornada do desenvolvedor headless do AEM, saiba mais sobre o que é necessário para iniciar seu próprio projeto com o AEM Headless.

A história até agora story-so-far

No documento anterior da jornada headless do AEM, Saiba mais sobre o desenvolvimento do CMS headless, você aprendeu a teoria básica do que é um CMS headless e agora deve:

Este artigo se baseia nesses fundamentos para que você entenda como usar o AEM para implementar uma solução headless.

Objetivo objective

Este documento ajuda você a entender o AEM headless no contexto de seu próprio projeto. Depois de ler esse documento, você deverá:

Noções básicas do AEM aem-basics

Antes de definir seu projeto headless no AEM, é importante entender alguns conceitos básicos do AEM.

Instância do autor author

Em sua forma mais simples, o AEM consiste em uma instância de autor e uma instância de publicação que trabalham em conjunto para criar, gerenciar e publicar seu conteúdo.

O conteúdo começa na instância do autor. É aqui que os autores de conteúdo criam o conteúdo. O ambiente de criação oferece várias ferramentas para que os autores criem, organizem e reutilizem o conteúdo.

Instância de publicação publish

Depois que o conteúdo é criado na instância do autor, ele deve ser publicado para estar disponível a outros serviços para consumo. Uma instância de publicação contém todo o conteúdo que foi publicado.

Replicação replication

Replicação é o ato de transferir conteúdo da instância do autor para a instância de publicação. Isso é feito automaticamente pelo AEM quando um autor ou outro usuário com direitos apropriados publica conteúdo.

Resumo das noções básicas do AEM aem-basics-summary

No nível mais simples, a criação de experiências digitais no AEM requer as seguintes etapas:

O AEM headless desenvolve essa base técnica, oferecendo ferramentas eficientes para gerenciar conteúdo headless que é descrito na próxima seção.

Noções básicas do AEM Headless aem-headless-basics

Os recursos headless do AEM são baseados em alguns recursos principais. Eles são explicados em detalhes em partes posteriores da jornada. É importante agora apenas saber o básico do que eles fazem e como são chamados.

Modelos de fragmentos do conteúdo content-fragment-models

Os Modelos de fragmento de conteúdo definem a estrutura dos dados e do conteúdo que você irá criar e gerenciar no AEM. Eles servem como uma espécie de andaime para o conteúdo. Ao optar por criar o conteúdo, os autores escolherão entre os Modelos de fragmento de conteúdo definidos, que os orientarão na criação do conteúdo.

Fragmentos de conteúdo content-fragments

Os fragmentos de conteúdo permitem projetar, criar, preparar e publicar conteúdo independente de página. Eles permitem preparar conteúdo pronto para uso em vários locais e em vários canais.

Fragmentos de conteúdo contêm conteúdo estruturado e podem ser entregues no formato JSON.

APIs GraphQL e REST apis

Para modificar o conteúdo de forma headless, o AEM oferece duas APIs robustas.

Você aprenderá sobre essas APIs e como usá-las em uma parte posterior da jornada headless do AEM. Ou consulte a seção recursos adicionais abaixo para obter a documentação adicional.

Níveis de integração headless integration-levels

O AEM oferece suporte aos modelos headless completo e tradicional de pilha completa ou headful de um CMS. No entanto, o AEM oferece não apenas essas duas opções exclusivas, mas também a capacidade de oferecer suporte a modelos híbridos que combinam as vantagens de ambos, oferecendo flexibilidade exclusiva para seu projeto headless.

Para garantir sua compreensão dos conceitos headless, esta Jornada do desenvolvedor headless do AEM se concentra no modelo headless puro para colocá-lo em funcionamento o mais rápido possível, sem codificação no AEM.

No entanto, você deve estar ciente das possibilidades híbridas adicionais abertas a você depois de entender os recursos headless do AEM. Esses casos são descritos abaixo para sua percepção. No final da jornada, você será apresentado a esses conceitos com mais detalhes caso essa flexibilidade seja necessária para o seu projeto.

Você já tem um consumo externo de conteúdo headless, como um aplicativo de página única (SPA). already-have-a-spa

Vamos supor que seu requisito básico seja no mínimo fornecer conteúdo do AEM para um serviço externo já existente.

Nível 1: Integração de fragmentos de conteúdo - Modelo headless tradicional level-1

Esse nível de integração é o modelo headless tradicional e permite que os autores de conteúdo criem conteúdo no AEM e o entreguem de forma headless a qualquer número de serviços externos usando o GraphQL ou que editem de serviços externos usando a API de ativos. Nenhuma codificação é necessária no AEM.

Neste modelo, o AEM é usado apenas para criar e distribuir o conteúdo usando os Fragmentos de conteúdo do AEM. A renderização e a interação com o conteúdo são delegadas ao aplicativo externo consumidor, geralmente um aplicativo de página única (SPA).

Nível 2: Incorporação do SPA no AEM - Modelo híbrido level-2

Esse nível de integração baseia-se no primeiro nível, mas também permite que o aplicativo externo (SPA) seja incorporado no AEM para que os autores de conteúdo possam visualizar o conteúdo no contexto do aplicativo externo dentro do AEM. O aplicativo também pode oferecer suporte à edição limitada do aplicativo externo dentro do AEM.

Esse nível tem a vantagem de permitir que os autores de conteúdo criem conteúdo de forma flexível no AEM de uma maneira headful, com o conteúdo apresentado em contexto com um SPA externo incorporado, enquanto ainda entregam o conteúdo de forma headless.

Nível 3: SPA incorporado e totalmente ativado no AEM - Modelo híbrido level-3

Esse nível de integração baseia-se no nível dois, permitindo que a maioria do conteúdo no SPA externo seja editável no AEM.

Você ainda não tem um consumidor externo do conteúdo headless, como um aplicativo de página única (SPA). do-not-have-a-spa

Se o objetivo for criar um SPA que consuma conteúdo sem periféricos do AEM, você poderá usar recursos como Fragmentos de conteúdo para gerenciar seu conteúdo sem periféricos e também criar um SPA AEM SPA com o Editor.

Usando o Editor de SPA, o SPA não apenas consome conteúdo do AEM, como também é totalmente editável dentro do AEM pelos autores de conteúdo, proporcionando a flexibilidade da entrega headless e da edição no contexto dentro do AEM.

Requisitos e pré-requisitos requirements-prerequisites

Há vários requisitos antes de começar seu projeto de AEM headless.

Conhecimento knowledge

Ferramentas tools

Definindo o seu projeto defining-your-project

Para qualquer projeto bem-sucedido, é importante definir claramente não apenas os requisitos do projeto, mas também as funções e responsabilidades.

Escopo scope

É importante ter um escopo claramente definido para o projeto. O escopo informa os critérios de aceitação e permite que você estabeleça uma definição de concluído.

A primeira pergunta que você deve fazer é “O que estou tentando alcançar com AEM Headless?” A resposta geral deve ser que você tem ou terá no futuro um aplicativo de experiência que você criou com suas próprias ferramentas de desenvolvimento, não com AEM. Esse aplicativo de experiência pode ser um aplicativo móvel, um site ou qualquer outro aplicativo de experiência voltado para o cliente final. O objetivo de usar o AEM Headless é alimentar seu aplicativo de experiência com conteúdo criado, armazenado e gerenciado no AEM com APIs de última geração que chamariam o AEM Headless para buscar conteúdo ou até mesmo conteúdo totalmente CRUD diretamente do seu aplicativo de experiência. Se isto não é o que você pretende fazer, então você provavelmente deve voltar para a documentação do AEM e encontrar a seção que melhor se adapta ao que você deseja realizar.

Funções e responsabilidades roles-responsibilities

As funções de qualquer projeto individual variam, mas as funções importantes a serem consideradas no conteúdo do desenvolvimento headless do AEM são:

Administrador administrator

O administrador é responsável pelas definições básicas e a configuração do sistema. Por exemplo, o administrador configura sua organização no sistema de gerenciamento de usuários da Adobe, referido ao Identity Management System (IMS). O administrador é o primeiro usuário da organização a receber um convite por email da Adobe depois que sua organização tiver sido criada pela Adobe no IMS. O administrador tem a capacidade de fazer logon no IMS e adicionar usuários de outros perfis.

Depois que os usuários são configurados pelo administrador, eles recebem as permissões para acessar todos os recursos do AEM e realizar seu trabalho como colaboradores para fornecer o aplicativo de experiência usando o AEM Headless.

O administrador deve ser o usuário que configura o AEM e prepara o ambiente de tempo de execução para habilitar os autores de conteúdo para criar e atualizar conteúdo e desenvolvedores para usar as APIs que buscam ou modificam o conteúdo para seus aplicativos de experiência.

Autor de conteúdo content-author

Os autores de conteúdo criam e gerenciam o conteúdo que é entregue de forma headless pelo AEM. Os autores de conteúdo usam recursos do AEM como Fragmentos de conteúdo e o console de Ativos para gerenciar seu conteúdo.

Os autores de conteúdo devem ter em mente as seguintes práticas recomendadas:

Planejamento para a tradução translation

Planeje a tradução bem no início do projeto. Considere o “especialista em tradução” como um perfil separado, cuja responsabilidade é definir qual conteúdo deve ser traduzido e qual não, além de qual conteúdo traduzido poderá ser modificado pelos produtores de conteúdo regionais ou locais.

Crie um plano sobre qual tradução de conteúdo você precisa.

Seja claro sobre o fluxo de trabalho de atualização de conteúdo. Qual é o processo de aprovação que o sistema deve oferecer suporte? Os fluxos de trabalho do AEM podem ser aproveitados para automatizar esse processo?

Observe que sua hierarquia de conteúdo pode ser usada para facilitar a tradução.

Consulte a seção recursos adicionais para obter a documentação adicional sobre fluxos de trabalho do AEM e ferramentas de tradução, incluindo links para a Jornada de tradução headless do AEM.

Aproveitar a hierarquia de conteúdo content-hierarchy

A hierarquia de pastas pode atender a duas principais preocupações com relação à gestão de conteúdo:

O AEM permite uma estrutura de conteúdo flexível e uma hierarquia pode ser arbitrariamente grande. No entanto, é importante perceber que qualquer alteração na estrutura de pastas pode ter consequências não intencionais para consultas existentes que dependem do caminho do conteúdo. Portanto, uma hierarquia bem definida, claramente definida previamente, pode ser útil para os autores de conteúdo.

As pastas também podem ser restritas para permitir apenas determinados tipos de conteúdo (com base nos Modelos de fragmento de conteúdo). É recomendável sempre especificar explicitamente quais modelos são permitidos para todas as pastas na hierarquia. Especificação do conteúdo permitido para uma determinada pasta:

Ao criar uma estrutura de conteúdo apropriada, fica mais fácil coordenar a criação de conteúdo headless entre canais para maximizar a reutilização do conteúdo. O aproveitamento do conteúdo em vários canais melhora muito a eficiência da produção de conteúdo e o gerenciamento de alterações.

Estabeleça boas convenções de nomenclatura naming-conventions

Os nomes dos Fragmentos de conteúdo devem ser descritivos para os autores de conteúdo. O AEM lida de forma transparente com o escape e/ou truncamento dos nomes usados nas IDs no nível do repositório. Portanto, os nomes lógicos fornecidos pelos autores de conteúdo devem sempre ser legíveis e representar o conteúdo.

Consulte a seção recursos adicionais para obter documentação adicional sobre convenções de nomenclatura da página do AEM.

Não estender o aninhamento de conteúdo em excesso content-nesting

Fragmentos de conteúdo são usados no AEM para criar conteúdo headless. O AEM aceita até dez níveis de aninhamento de conteúdo para Fragmentos de conteúdo. No entanto, é importante ter em mente que o AEM deve resolver iterativamente cada referência definida no Fragmento de conteúdo principal e verificar se há referências filho em todos os irmãos. Essas operações podem aumentar rapidamente e se tornar uma preocupação de desempenho.

Como regra geral, as referências do Fragmento de conteúdo não devem ser aninhadas além de cinco níveis.

Arquiteto de conteúdo content-architect

Os arquitetos de conteúdo analisam os requisitos para os dados que devem ser entregues de forma headless e definem a estrutura desses dados. Essas estruturas são chamadas de Modelos de fragmentos de conteúdo no AEM. Os Modelos de fragmentos de conteúdo são usados como a base dos Fragmentos de conteúdo criados pelos autores do conteúdo.

Uma abordagem útil ao definir Modelos de fragmento de conteúdo é criar modelos que mapeiam para os componentes da UX dos aplicativos que consomem o conteúdo.

Como os autores de conteúdo interagem com os modelos continuamente à medida que criam novo conteúdo, o alinhamento dos modelos à UX os ajuda a visualizar a experiência digital resultante. Levando esse alinhamento um passo além, você pode atribuir ícones aos Modelos de fragmento de conteúdo que representam o elemento de UX para que os autores possam intuitivamente selecionar o modelo correto com base em dicas visuais.

Desenvolvedor developer

Os desenvolvedores são responsáveis por unir o conteúdo que está sendo criado de forma headless no AEM ao consumidor desse conteúdo, que geralmente pode ser um aplicativo de página única (SPA), um aplicativo Web progressivo (PWA), uma loja virtual ou outro serviço externo ao AEM.

O GraphQL é como se fosse a “cola” entre o AEM e os consumidores de conteúdo headless. O GraphQL é o idioma que consulta o AEM para o conteúdo necessário.

Os desenvolvedores devem ter em mente algumas recomendações básicas ao planejar suas consultas:

Para uma implementação headless típica usando o AEM, o desenvolvedor não precisa ter conhecimento de codificação do AEM.

Requisitos de desempenho performance-requirements

Para que qualquer projeto seja um sucesso, o desempenho deve ser considerado antes que qualquer conteúdo seja criado.

Compreenda suas expectativas de usuários/visitantes e o design para eles. Defina objetivos de nível de serviço (SLOs) e os meça para entender se você atende às expectativas de seus usuários.

Padrões de tráfego traffic-patterns

Para entender tráfego e os padrões de tráfego, comece reunindo o que você sabe do passado e projete para o crescimento esperado nos próximos anos. Algumas das variáveis mais importantes a serem consideradas:

Frequência das atualizações update-frequency

Frequentemente, diferentes seções de experiências têm frequências diferentes de atualizações de conteúdo. Entender isso é importante para poder ajustar as configurações de CDN e cache. Isso também é importante para o Arquitetos de conteúdo conforme criam modelos para representar seu conteúdo. Considere:

O que vem a seguir what-is-next

Agora que concluiu esta parte da jornada de desenvolvedores headless do AEM, você deve:

Você deve continuar sua jornada headless no AEM revisando o documento a seguir: Caminho para Sua Primeira Experiência Usando AEM Headless onde aprenderá a configurar as ferramentas necessárias e como começar a pensar em modelar seus dados no AEM.

Recursos adicionais additional-resources

Mesmo sendo recomendado que você siga para a próxima parte da jornada de desenvolvimento headless revisando o documento Caminho para Sua Primeira Experiência usando AEM Headless, a seguir estão alguns recursos adicionais e opcionais que fazem uma análise mais profunda sobre alguns conceitos mencionados neste documento, mas eles não são requisitos para continuar na jornada headless.