Headless: GraphQL with Content Fragments

Transcript

Welcome everyone to the headless session, GraphQL with content fragments. This is Jabran Asghar. I’m a senior software engineer at Adobe and member of the team developing headless features for AEM. I’m also joined today by Mathias Siegel from AEM product management for sharing updates on the headless strategy and Stefan Grin from AEM engineering team to follow up questions in the session chat. A technical note about the presentation, you can double click on the presentation slides to make them a bit larger. During the last couple of months, AEM engineering team developed some very exciting features to add headless content delivery features to AEM. In this session, we shall explore key AEM enhancements for headless content delivery followed by a live demo on AEM cloud service. I will ask now Mathias Siegel from AEM product management to share updates on AEM content delivery and management strategy. Mathias, please take the stage. Yeah, thanks Jabran. On the slide here, you can see the areas that’s keeping us busy for the last couple of months as Jabran mentioned for headless content management. But in fact, headless content management is not even a new thing with AEM. As many of you will know, content fragments and the ability to manage structured content goes a number of years back to about AEM 6.2, 6.3 when we started content fragments. And in fact, the architecture of AEM goes back to what today is called headless management, headless content management or better decoupled content architectures to the very beginnings of the system. So at a time back in the days before there was such a thing called headless content management, AEM was built in a decoupled architecture compared with other systems back then who used a proprietary database for content storage and proprietary application layers. That’s when AEM started with a back then already decoupled content repository, a Java content repository. With a open source Java content repository being open source, but also an open source application layer, the Sling application layer, web application layer based on RESTful principles. Back then already in the days before there was headless content management and the onslaught of JavaScript frameworks. And leveraging that Sling application layer is where we over the years have added headless content management features, capabilities, and principles. So that not only that you can implement AEM in a headless fashion, but you can also mix and match the different implementation patterns. Starting from core components, for example, which feature Sling model exporters to export JSON to hybrid content management with the SPA editor, which uses internally in the SPA editor a graph of JSON as a data exchange format between components to now pure and native API based content delivery with a GraphQL API that we also build based upon the Sling application layer in order to allow a pure headless implementation of AEM that exposes the content repository through a content API directly to client applications in the front end. And the way how this works in detail and what’s entailed in all these great and very exciting new features, I’ll hand it back to Jarvan, who’s going to take you through the rest of the session. Thank you, Matthias. Let’s continue exploring headless capabilities of AEM starting with content fragment models and graph query types. A quick refresher for content fragment models. Content fragment models are content schemas to define structure of content that you want to publish. They are presentation agnostic and can be used for multiple channels like mobile apps, single page applications, or any other system requiring to consume them. Here you see a content fragment model structure A with two content fragments defined with the actual values conforming to the structure of the model. One of the key headless features is to generate GraphQL types for AEM content fragment models and thus enabling you to curate those GraphQL types to get the actual content. For example, consider the article model structure here. The GraphQL type generated from the article content fragment model looks like this. Note that there are some additional fields, for example, underscore parts, which are auto-generated for GraphQL types for all content fragment models. In the query, you can specify exact data fields that you want to achieve and the same you get in the JSON result from GraphQL query execution. An interesting part in the result is the value of the main field. The value itself is a JSON object and shows HTML format for the value. We shall see later in the demo that AEM APIs for headless can return multiple formats for a given multi-line string value. GraphQL types and schemas for content fragment models are generated by AEM headless API. There is nothing you need to do to do that except creating content fragment models as you normally do. When writing queries to retrieve data, these are the features that you can use in the GraphQL queries. Mutation and subscriptions are yet not supported. Paging and sorting features can be rolled out in an upcoming release. Let’s explore now content fragment modeling enhancements in Adobe Experience Manager. We added two new data types which are of particular interest in relation to GraphQL. The first new data type is the fragment reference type, which enables one content fragment model to reference another model. For example, here you see three content fragment models, A, B, and C. And model A is referencing to model B and B is referencing to model C. When retrieving the content fragments of model A via GraphQL, the reference fragments of model B and C can also be retrieved. This feature can be used to define additional layers of structure when defining content fragment models. The other new data type is JSON data type, enabling you to specify a JSON value. This JSON value is passed through to JSON output in a GraphQL query result and thus is returned as a JSON scaler. For example, the book model here has an info field of type JSON and accordingly the GraphQL type for that model has also that field as of JSON type. In the corresponding content fragment, the JSON value has been specified for that field. The query result for this content fragment model contains value of the info field as a JSON scaler. JSON scaler means its properties cannot be specified or filtered upon in the GraphQL query. It’s just passed through to the JSON output. From a UI perspective, the content fragment model editor also validates the JSON value format as well as provides syntax highlighting. Now let’s look at the content fragment editor enhancements to streamline AEM user experience. There is a new structure tree feature to let you easily navigate through the different fields of a content fragment. It also shows any reference content fragments and their fields. There is now a possibility to easily access the model of a content fragment. For example, you see the link to the article model on top of the UI. Further, any reference content fragments can be directly edited from the prime content fragments. One very interesting feature is JSON preview. It provides you with a JSON view of the current content fragment. This can be helpful in writing GraphQL queries for more complex content. Then there is a possibility to publish a content fragment instantly while editing. This one is an upcoming feature in a post-GA update. GraphQL is a tool for developers to write and test GraphQL queries. It provides syntax highlighting, auto-completion for model names and their fields, as well as schema documentation blocks. We are providing a GraphQL content package for AEM which can be downloaded from Adobe Software Distribution. Please note that this package is supposed to be used on development AEM instances only. When delivering huge amounts of headless content, performance and scaling can become a challenge very easily. We are providing a persistent queries feature to support such huge scaling. The idea is simple from the outside. Generally, GraphQL queries work over HTTP via post requests, or at least preferable so due to different limitations of catch requests. So you write your queries and save them via put request in AEM as persistent queries under simple names. As a result, you receive the short path of the query. And then you use this short path of the query to execute the query via a simple get request so that the query itself and the results can be cached. Persistent queries can be enabled per AEM account via AEM configuration console. Please note that this is an upcoming feature which we shall roll out soon to the AEM cloud service. Now we shall show a demo of AEM headless capabilities. So we start with the Adobe Experience Manager. We have a couple of content fragment models as the adventure article and bookmark. Let’s continue with the content fragment model adventure. Here you see a number of fields, different fields that are used in the adventure model. In particular, the fragment reference field, which is pointing to a model of type article. Let’s move on to the fragment editor. Here we have a couple of content fragments. Let’s check the Bivana Portland fragment, which has a couple of images and some content. Looking at the content fragment itself, we have the feature structure tree, which allows to navigate easily throughout the fields of the content fragment. Let’s go to the article reference field, which is a reference to another model. And you have the possibility to edit the content fragment directly from here. Also, you have the link of the adventure model, which you can directly go. Now looking at the JSON preview feature, you get the content fragment as if it will be returned by the JSON output. An interesting feature here is that the rich text contents are delivered in four different formats. HTML, Markdown, CleanText and JSON. And they are auto-converted from one given format to the other by the headless API. Moving on to the GraphQL editor, where you have the possibility to test and execute various queries before actually putting them into production. Let’s start with getting a simple list of adventures. So this query returns all the parts for the given content fragments for adventure model. Here, the query is basically fetching adventure models along with their referenced articles. So here you see the normal content plus the article reference and the fields of the article reference. Here is the only HTML field because we specified only HTML. And we can specify here different other formats, like you see the auto-completion from the editor. And we get the results accordingly. There are various other possibilities like filtering content. Here we are filtering adventure fragment models, fragment contents based on the campaign type. Then we have the possibility to use variables. For example, we are getting here a variation which has the type UK. Then there is a possibility to use directives. For example, in this query, we want to include the adventure price if we want it, otherwise we want to emit it. When we have this included price value true, the field is included. And if we have it false, the field will be excluded from the result. Then there are complex possibilities to use logical operators. For example, here we are getting a list of persons and we want to get the persons whose name is either Jobs or Sue. So now we have all content fragment models, we have content fragments and we have the headless API on top of that. Using all of this, we have this… Shabranz? Yes? Sorry for interrupting. Can you zoom in? There’s a couple of comments that ask if you can zoom in in the browser. Just command plus a couple of times. Okay, sorry. Sorry. Cool, that’s better. So we have now a simple React application, which is using AM service, AM Cloud as a service, and getting the content fragments of adventure type from AM. So here we have all content fragments, then we can filter, for example, based on the campaign category and that perspective. If you look at the code size, so we have endpoint being used from the GraphQL, headless API, and then we are rendering, we are using the same queries that we just saw, like adventure list or the filter query. And the result is rendered by this code fragment. So simple is for customers to build experiences using AM headless API. Now moving on to further. AM headless capabilities modernize and simplify building new experiences. You get enhanced modeling capabilities, a streamlined AM user experience, accompanied by an industry standard for curing content headless. So what to do next? There is a detailed documentation on experience-league.adobe.com, which will give you a quick start into AM headless GraphQL APIs. Adobe Experience Manager is all about building world class experience for customers. With headless GraphQL API, AM is modernizing the way customers can build experiences to reach their audience at scale. We just released the headless CMS enhancement and GraphQL API in the most recent public release of AM as a cloud service. This was just last week. In addition to the public release of AM headless enhancements, we are also working on significant Adobe internal use cases for using AM in a headless fashion. So if you are interested in headless capabilities, single page applications, or IoT projects, we should be very happy to provide you more information with that. Please follow up with your Adobe representative now. There is also an interest poll available in the session chat. Please take a few moments to provide your input. Thank you very much for your time and attention. Happy playing headless on Adobe Experience Manager.