Author and Publish Architecture

Hello and welcome to the Adobe Experience Manager headless series. In this video, we will take a look at AEM’s Publish Architecture and how to deploy your content and headless application in a production setting. Before getting started, let’s take a quick look at our learning objectives for this video. We will spend some time reviewing the high-level headless application architecture. This will include a review of AEM’s site where we will review the role of your third-party application for delivering both preview and live content. Then we will recap the basics of content publishing. For this tutorial, we will cover how to publish content fragment models, content fragments and GraphQL Persistent Queries. By the end of this video, you should have a good understanding of these core concepts. Author published architecture, author published architecture, and author published architecture. Headless content publishing, preview versus live content, and how to integrate your third-party application as a preview application for your consumers. In a traditional Adobe Experience Manager site’s implementation, AEM is responsible for owning and delivering the web experience. However, when AEM is used as a headless CMS, it’s only responsible for delivering content via a JSON-based API, in our case, GraphQL Endpoints. In this model, third-party applications own the presentation and use AEM as a headless service. Third-party applications can include mobile applications, single-page applications, desktop applications, and other clients that can communicate over HTTP. In the headless architecture, AEM no longer controls the user experience. This requires applications to provide a presentation for both the live delivery of content to end-users as well as the presentation to preview editorial changes. In this video, we will create and edit our content on an AEM author instance, then publish it to a publish instance once the content fragment models, content fragments, and GraphQL Persisted Queries are ready for end-user consumption. In order to preview changes prior to publication, we will connect a sample React-based application to our author instance. Lastly, we will connect the second instance of our React application to our publish instance to allow end-users to interact with live content. Now that we have an understanding of the headless architecture, let’s take our content and author and publish it. It’s important to understand the relationships between the various headless resources, such as content fragment models, content fragments, and other reference content, like images. All reference assets must be published. Let’s start by reviewing the relationships that exist in the Weekend Share project. We will navigate to Content Fragments. Next, select the downhill skiing Wyoming content fragment. Recall that this content fragment has one fragment reference, a one-to-many relationship to the contributor content fragment model using the fragment reference data type. Now click Publish, then select Now. We will include all references and click Publish. Refresh your browser to confirm that all references have been successfully published. Now that we have all references published, let’s validate our content by executing a GraphQL query. We will use the GraphQL explorer and query the content fragment that we just published using the adventure bipath query tag. Notice that our adventure response contains related content fragments, such as the contributor’s reference. Before leaving this topic, it’s important to remember headless applications must interact with headless GraphQL through Persisted queries. The use of client-side or ad hoc defined queries are only to be used for exploring AEM headless APIs and defining Persisted queries. To save our query for future use, we can click on the Save As button and give it a name.

Once we’ve saved our query, we can publish it by clicking on the Publish button. To ensure that our Persisted query has been successfully published, we can issue a GET request in a web browser to the Persisted query endpoint. Let’s try this out by selecting Copy URL.

As you can see, we have a valid response. Now that we have all of our models, content, reference assets, and queries published, we are ready to connect a third-party application to Adobe Experience Manager. We will start by deploying a simple React-based application and connect it to our publish instance. This will simulate a production application deployment in which end-users can consume live content. In order to follow along, you will need a recent version of Node.js and a Git client installed on your system. First, check out the AEM Guides Weekend GraphQL project from GitHub. Once the project is checked out, open your favorite IDE. Then open env-development and set the React-app-host URI variable to your publish instance. Save your changes and then open one more file. Under Source, open setup-proxy.js. This file indicates the type of authentication to use when connecting to AEM. There are four options. Service token, development token, HTTP basic authentication, and none. Since this is a production application serving live production content, no authentication to AEM is necessary. The default is set to none, so we can leave it this way. Install the application dependencies by using npm install and then start the application using npm start. Now let’s launch a web browser and open our headless application. The application’s initial view displays a list of adventures. Behind the scenes, a persisted list query called adventure-all to collect these adventures from AEM. As an exercise, open your browser’s web developer tools and inspect the AEM headless GraphQL queries. There are two important takeaways from this example. The first is that the third-party React application owns the presentation and is simply making requests to AEM via GraphQL queries to obtain application data. And second, since the application is pointing at the publish instance, only live content is presented to the user. Remember that content changes in author do not impact the application until they are published. Before concluding on, let’s briefly discuss AEM’s cross-origin resource sharing configuration. By default, and for security, AEM does not allow cross-origin requests or CORS from other domains. So, for example, if your headless app is running on example.com and it is trying to connect to your AEM environment on something other than example.com, CORS is required for your app to communicate with AEM headless APIs. For instructions on how to set CORS up for AEM, please review the AEM documentation. This concludes the author and publish architecture tutorial. Thank you for joining us and stay tuned for future videos in the headless series.