Caminho para sua primeira experiência usando o AEM Headless path-to-first-experience

Nesta parte da jornada de desenvolvedor do AEM Headless, você entenderá as etapas para implementar sua primeira experiência headless no AEM, incluindo considerações de planejamento e práticas recomendadas para facilitar ao máximo o seu percurso.

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

No documento anterior da jornada AEM headless, Introdução ao AEM 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 preparar seu próprio projeto do AEM Headless.

Objetivo objective

Este documento ajuda você a entender as etapas necessárias para implementar seu primeiro projeto. Após ler esse documento, você deve:

Requisitos requirements

Antes de continuar com este documento, verifique se você revisou o documento anterior na Jornada para desenvolvedores AEM Headless, Introdução ao AEM Headless, certificando-se de:

Planejamento para o sucesso planning-for-success

Para iniciar seu primeiro projeto headless do AEM, é necessário garantir que você tenha um modelo de conteúdo compatível com a personalização e as atualizações que deseja fazer em todos os canais.

Separado do AEM, também é necessário garantir que você tenha um ambiente de desenvolvimento adequado configurado, caso esteja criando um aplicativo do lado do cliente para que você possa testar seu cliente em relação às chamadas de API para AEM.

Definição de modelos de conteúdo e APIs defining-models

Você deseja oferecer uma experiência consistente e gerenciar campanhas personalizadas em todos os canais, para que possa visualizar cada canal e superfície individualmente como sua própria estrutura de conteúdo distinta para entrega. No entanto, ter cada canal com seu próprio modelo de conteúdo é algo muito difícil de se manter.

Em vez disso, você deve considerar como o conteúdo em diferentes superfícies está relacionado com base no princípio de organização, como hierarquias de marca e produto, categorias de mercadorias ou superfícies, ou etapas na jornada do cliente. Por exemplo, se você tiver um conjunto de superfícies compatíveis com uma marca específica de carros que você fabrica, talvez queira começar com um modelo de conteúdo para informações gerais que sejam relevantes para o carro inteiro, e então utilizar alguns elementos mais específicos, como o conteúdo necessário para quando o carro estiver dando partida ou quando houver problemas de manutenção. Tal modelo imporá a herança do conteúdo geral da marca de carro e permitirá mudanças com base no contexto específico necessário. Isso também ajuda na gestão de futuras atualizações desse conteúdo, pois é possível impor o controle com base em funções, como o profissional de marketing geral ou o gerente de produto da marca de carro, em comparação com um autor responsável pela experiência de “dar a partida no carro”.

Depois de ter o modelo de conteúdo e uma visão nítida dos vários clientes aos quais o conteúdo precisa ser exibido, é necessário garantir que as APIs GraphQL que permitem o acesso a vários modelos de conteúdo sejam publicadas para todos os clientes que precisam desse conteúdo. Há diferentes opções para se acessar um determinado conteúdo. Você pode solicitar um conteúdo específico que seja estático, o que permite o armazenamento em cache do conteúdo e melhor desempenho. Você também pode solicitar um conteúdo gerado dinamicamente, o que exigirá mais processamento. Certifique-se de que os clientes estejam usando as APIs mais eficientes para suas necessidades comerciais.

Entender os ambientes understanding-environments

No AEM há três tipos de ambientes: desenvolvimento, preparo e produção.

Os ambientes de desenvolvimento (você pode ter vários) são um local seguro para experimentar e tentar novas ideias. Durante a fase inicial do projeto, a Adobe recomenda o uso dos ambientes de desenvolvimento para experimentar variações de modelos de conteúdo e ver quais fornecem o resultado pretendido para as superfícies.

O ambiente de preparo para projetos headless é usado para validar novas versões de produtos do AEM antes de serem implantados na produção. Mantenha uma lista atualizada dos modelos de conteúdo de produção disponíveis lá e utilize um subconjunto do conteúdo, para que você possa renderizar arquivos JSON e comparar se eles ainda fornecem o mesmo resultado, à medida que novas alterações são feitas por você ou por uma nova versão do AEM

A produção é onde os autores de conteúdo criam e gerenciam seu conteúdo real. As mudanças de modelo na produção devem ser realizadas com cuidado e tendo em mente a compatibilidade com versões anteriores.

Durante o estágio de desenvolvimento, é recomendável trabalhar com um ambiente de desenvolvimento e preparo. À medida que você migra para o teste de desempenho, desejará migrar para o ambiente de produção.

Cooperação de desenvolvedores e autores de conteúdo cooperation

Os desenvolvedores precisam de um ambiente de desenvolvimento do AEM configurado com os modelos de conteúdo preenchidos. O desenvolvedor cria o cliente que consumirá conteúdo do AEM Headless enquanto os autores de conteúdo ainda estão criando o conteúdo. É por isso que as definições de API são realmente importantes. Ao usar o SDK do AEM, o desenvolvedor pode criar um gancho de teste para que testes de cliente e unidade possam ser criados para garantir que o cliente possa renderizar o conteúdo corretamente.

Os autores de conteúdo criam conteúdo com base nos modelos de conteúdo que foram definidos no ambiente de preparo. Usando a ferramenta de criação de fragmento de conteúdo, o autor criaria um fragmento de conteúdo ou editaria um fragmento de conteúdo existente. Antes de publicá-lo, o autor pode visualizar como será a aparência no cliente, trabalhando com o desenvolvedor para mover o modelo de conteúdo para o desenvolvimento ou configurar um ambiente de desenvolvedor apenas para que os autores visualizem a aparência dele no cliente.

Configurar setup

Antes de começar a usar o headless no AEM, você precisa garantir que todos os recursos necessários estejam habilitados. Esta seção descreve o que é necessário. As etapas serão mais detalhadas posteriormente na Jornada do desenvolvedor do AEM Headless.

Você também pode consultar os recursos adicionais para obter mais informações sobre os tópicos individuais.

Configuração configuration

Implementar seu primeiro aplicativo headless do AEM

Esta é uma visão geral do que é necessário para implementar seu primeiro aplicativo headless usando o AEM para distribuir o seu conteúdo. Como executar essas etapas será descrito mais detalhadamente em partes posteriores da jornada do desenvolvedor headless.

Práticas recomendadas best-practices

Um projeto headless não é bem-sucedido apenas devido à tecnologia implementada, mas também por conta do bom planejamento e governança do projeto. A seguir estão várias práticas recomendadas para que os autores e desenvolvedores de conteúdo se lembrem ao planejar o projeto.

Organizar seu conteúdo organizing-content

Criar conteúdo authoring

Criação de conteúdo global localization

O que vem a seguir what-is-next

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

Queremos que você se baseie nesse conhecimento fundamental para entender toda a eficiência e flexibilidade do AEM Headless, aproveitando-as em seus próprios projetos. Para fazer isso, você tem algumas opções.

Escolha sua própria aventura choose-your-path

Não importa qual o seu estilo de aprendizagem, a Adobe quer que você tenha sucesso à medida que inicia seu projeto do AEM Headless.

Recursos adicionais additional-resources

Embora seja recomendável seguir para a próxima parte da jornada de desenvolvimento headless revisando o documento Como modelar seu conteúdo como Modelos de conteúdo do AEM, veja a seguir alguns recursos adicionais e opcionais que aprofundam alguns conceitos mencionados neste documento, mas que não são necessários para continuar na jornada headless.