Nesta parte do AEM Jornada de desenvolvedor sem periféricos, saiba mais sobre o que é necessário para iniciar seu próprio projeto com AEM Headless.
No documento anterior da jornada sem cabeçalho AEM, Saiba mais sobre o desenvolvimento sem periféricos do CMS você aprendeu a teoria básica do que é um CMS sem periféricos e agora deve:
Este artigo se baseia nesses fundamentos para que você entenda como usar o AEM para implementar uma solução sem periféricos.
Este documento ajuda você a entender AEM headless no contexto de seu próprio projeto. Depois de ler, você deve:
Antes de definir seu projeto sem periféricos no AEM, é importante entender alguns conceitos básicos de AEM.
Em sua forma mais simples, o AEM consiste em uma instância de autor e um 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 seu conteúdo. O ambiente de criação oferece várias ferramentas para que os autores criem, organizem e reutilizem seu conteúdo.
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 é o ato de transferir conteúdo da instância do autor para a instância de publicação. Isso é feito automaticamente por AEM quando um autor ou outro usuário com direitos apropriados publica conteúdo.
No nível mais simples, a criação de experiências digitais no AEM requer as seguintes etapas:
AEM a base técnica é desenvolvida com facilidade, oferecendo ferramentas poderosas para gerenciar conteúdo sem interface, que é descrito na próxima seção.
Os recursos sem periféricos do AEM são baseados em alguns recursos principais. Elas são explicadas em detalhes em partes posteriores da jornada. Agora é importante apenas conhecer os princípios básicos do que fazem e do que são chamados.
Os Modelos de fragmentos de conteúdo definem a estrutura dos dados e do conteúdo que você cria e gerencia no AEM. Eles servem como uma espécie de andaime para o conteúdo. Ao optar por criar o conteúdo, os autores selecionam entre os Modelos de fragmento de conteúdo definidos, que os orientam na criação do conteúdo.
Os fragmentos de conteúdo permitem projetar, criar, preparar e publicar conteúdo independente de página. Eles permitem que você deixe o 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.
Para modificar o conteúdo sem interrupções, o AEM oferece duas APIs robustas.
Você aprenderá sobre essas APIs e como usá-las em uma parte posterior da jornada sem periféricos AEM. Ou consulte a recursos adicionais para obter a documentação adicional.
O AEM suporta tanto a pilha completa como a pilha completa tradicional ou os modelos impiedosos de um CMS. No entanto, AEM oferece não apenas essas duas opções exclusivas, mas a capacidade de suportar modelos híbridos que combinam as vantagens de ambas, oferecendo flexibilidade exclusiva para seu projeto sem periféricos.
Para garantir a compreensão dos conceitos sem periféricos, essa Jornada de desenvolvedores sem periféricos AEM se concentra no modelo sem periféricos puro para fazer você funcionar o mais rápido possível sem codificação na AEM.
No entanto, você deve estar ciente das possibilidades híbridas adicionais abertas a você, assim que entender AEM recursos headless. Esses casos são descritos abaixo para sua consciência. No final da jornada, você será apresentado a esses conceitos com mais detalhes caso essa flexibilidade seja necessária para o seu projeto.
Vamos supor que seu requisito básico é o mínimo para fornecer conteúdo de AEM para um serviço externo existente.
Esse nível de integração é o modelo sem cabeçalho tradicional e permite que os autores de conteúdo criem conteúdo no AEM e o entreguem sem aviso a qualquer número de serviços externos que usam GraphQL ou para editá-los a partir de serviços externos usando a API do Assets. Nenhuma codificação é necessária no AEM.
Neste modelo, o AEM é usado apenas para criar e veicular o conteúdo usando Fragmentos de conteúdo AEM. A renderização e a interação com o conteúdo são delegadas ao aplicativo externo de consumo, geralmente um aplicativo de página única (SPA).
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 no AEM. O aplicativo também pode oferecer suporte à edição limitada do aplicativo externo no 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 sem interrupções.
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.
Se o objetivo for criar um novo SPA que consuma sem periféricos conteúdo de AEM, você poderá usar recursos como Fragmentos de conteúdo para gerenciar o conteúdo sem periféricos e também criar um SPA com AEM estrutura SPA Editor.
Usando o Editor de SPA, o SPA não apenas consome conteúdo de AEM, como também é totalmente editável em AEM pelos autores de conteúdo, proporcionando a flexibilidade da entrega sem periféricos e da edição no contexto dentro do AEM.
Há vários requisitos antes de iniciar seu projeto sem periféricos AEM.
Para qualquer projeto bem-sucedido, é importante definir claramente não apenas os requisitos do projeto, mas também as funções e responsabilidades.
É importante ter um âmbito 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 sem Cabeça?" A resposta deve ser, em geral, que você tem ou terá no futuro um aplicativo de experiência que você criou com suas próprias ferramentas de desenvolvimento e 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 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 pretende fazer, provavelmente quer volte para a documentação do AEM e encontre a seção que melhor se adapta ao que você deseja realizar.
As funções de qualquer projeto individual variam, mas as importantes a serem consideradas no conteúdo AEM desenvolvimento sem periféricos são:
O administrador é responsável pela configuração básica do sistema. Por exemplo, o administrador configura sua organização no sistema de gerenciamento de usuários do Adobe, referido ao Sistema Identity Management (IMS). O administrador é o primeiro usuário da organização a receber um convite por email do Adobe depois que sua organização tiver sido criada pelo Adobe no IMS. O administrador tem a capacidade de fazer logon no IMS e adicionar usuários de outras personas.
Depois que os usuários são configurados pelo administrador, eles recebem as permissões para acessar todos os recursos de AEM para realizar seu trabalho como contribuidores no delivery do aplicativo de experiência usando AEM Headless.
O administrador deve ser o usuário que configura o AEM e prepara o ambiente de tempo de execução para ativar o autores de conteúdo para criar e atualizar conteúdo e desenvolvedores para usar APIs que buscam ou modificam o conteúdo de seus aplicativos de experiência.
Os autores de conteúdo criam e gerenciam o conteúdo que é entregue sem cabeçalho pelo AEM. Os autores de conteúdo usam AEM recursos 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.
Plano de tradução no início do projeto. Considere "Especialista em Tradução" como uma pessoa separada, cuja responsabilidade é definir qual conteúdo deve ser traduzido e o que não deve ser, e qual conteúdo traduzido pode 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 suportar? AEM workflows podem ser aproveitados para automatizar esse processo?
Observe que a hierarquia de conteúdo pode ser aproveitado para facilitar a tradução.
Consulte a recursos adicionais para obter a documentação adicional sobre fluxos de trabalho AEM e ferramentas de tradução, incluindo links para a Jornada de tradução sem cabeçalho AEM.
A hierarquia de pastas pode atender a duas principais preocupações com relação à gestão de conteúdo:
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 Confie no caminho do conteúdo. Portanto, uma hierarquia bem definida, claramente definida e 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, torna-se mais fácil coordenar a criação de conteúdo sem periféricos em todos os 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.
Os nomes dos Fragmentos de conteúdo devem ser descritivos para os autores de conteúdo. AEM lidar 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.
cta_btn_1
Call To Action Button
Consulte a recursos adicionais para obter documentação adicional sobre AEM convenções de nomenclatura de página.
Fragmentos de conteúdo são usados em AEM para criar conteúdo sem cabeçalho. AEM suporta até dez níveis de aninhamento de conteúdo para Fragmentos de conteúdo. No entanto, é importante ter em mente que AEM deve resolver iterativamente cada referência definida no Fragmento de conteúdo pai e verificar se há referências filho em todos os irmãos. Essas operações podem ser adicionadas rapidamente e se tornarem uma preocupação com o desempenho.
Como regra geral, as referências do Fragmento de conteúdo não devem ser aninhadas além de cinco níveis.
Os arquitetos de conteúdo analisam os requisitos para os dados que devem ser entregues sem periféricos e definem a estrutura desses dados. Essas estruturas são chamadas de Modelos de fragmentos do conteúdo em AEM. Os Modelos de fragmentos do conteúdo são usados como a base dos Fragmentos do 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 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 ao 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 UX para que os autores possam intuitivamente selecionar o modelo correto com base em dicas visuais.
Os desenvolvedores são responsáveis por unir o conteúdo que está sendo criado sem periféricos no AEM ao consumidor desse conteúdo, que geralmente pode ser um aplicativo de página única (SPA), um aplicativo da Web progressivo (PWA), uma loja da Web ou outro serviço externo ao AEM.
GraphQL serve como a "cola" entre o AEM e os consumidores de conteúdo sem interface. GraphQL é o idioma que consulta AEM o conteúdo necessário.
Os desenvolvedores devem ter em mente algumas recomendações básicas, pois planejam suas consultas:
ByPath
) para recuperar Fragmentos de conteúdo.
select *
O tipo queries que você pode criar em um banco de dados relacional.Para um implementação sem periféricos típica usando AEM, o desenvolvedor não requer conhecimento de codificação de AEM.
Para que qualquer projeto seja um sucesso, o desempenho deve ser considerado antes que qualquer conteúdo seja criado.
Você deve entender suas expectativas de usuários/visitantes e criar projetos para eles. Defina os SLOs (Service Level Objetives, objetivos de nível de serviço) e os meça para entender se você atende às expectativas do usuário.
Começar a entender o tráfego e os padrões de tráfego com o que você sabe do passado e depois projetar para o crescimento esperado nos próximos anos. Algumas das variáveis mais importantes a serem consideradas:
Frequentemente, diferentes seções de experiências têm frequências diferentes de atualizações de conteúdo. Entender isso é importante para ajustar as configurações de CDN e cache. Isso também é importante para o Arquitetos de conteúdo conforme eles criam modelos para representar seu conteúdo. Considere:
Agora que você concluiu esta parte da Jornada de Desenvolvedores sem Cabeça da AEM, você deve:
Você deve continuar sua jornada sem periféricos de AEM revisando o documento em seguida Caminho para sua primeira experiência usando AEM headless onde você aprenderá a configurar as ferramentas necessárias e a começar a pensar em modelar seus dados no AEM.
Embora seja recomendável seguir para a próxima parte da jornada de desenvolvimento sem periféricos revisando o documento Caminho para sua primeira experiência usando AEM headless, a seguir estão alguns recursos adicionais e opcionais que aprofundam alguns conceitos mencionados neste documento, mas não é necessário que eles continuem na jornada sem periféricos.