Headless Adobe Experience Manager Sites

Transcript

All right, everybody. It’s 2.16 PM here in California, right on the clock, one minute extra for stragglers. So let’s get the session started. This is session S113, Headless AM Sites, just to make sure that everyone feels comfortable being in the right session. We used to point that out explicitly for Adobe Summit conferences when we want to make sure that everybody who is in a certain ballroom makes sure they’re in the right presentation and doesn’t find out halfway through the presentation. This is not about digital asset management here. It’s about sites. So this is session S113. I’m going to be your host for the next 30 minutes. We’re going to talk about Headless AM Sites. My name is Matthias. I’m a product manager in the AM Sites product management team. And I’ve been doing this for about five, six years, maybe seven already, kind of stopped counting just recently. And I started right around AM 6.0, or even slightly before that, in fact, CQ56, 561, working on multi-site management launches, and then with AM 6.0 and 6.1 translation integration. So if you have any questions about that, I’m happy to discuss that too in the chat or after the session. And then took on content fragments, experience fragments, and especially in the last couple of years, as Headless really started taking off for AM and AM Sites, also together with other product manager colleagues the AM Sites Headless strategy. So wanted to share with you the latest on what’s going on with Sites and Headless, which sounds like an oxymoron potentially, but it’s actually not. And that is something that we really wanted to get across and also help you to feel comfortable with. If your peers and your companies or your partner organizations ask you about AM and Headless, and you hear people saying that, well, AM cannot be Headless, AM has been around for a long time, and AM does this and that, and has components, and does server-side HTML, and it can’t be Headless, that the response to that is it absolutely can be Headless. It is Headless, and it can be Headless, and not just fake Headless or marketing Headless, but actually technically Headless in such a way how any other Headless content management system out in the world can be used for multi-channel, multi-endpoint delivery, multi-experience delivery. AM can absolutely do the same thing too. On-premise managed services, but most importantly as a cloud-native service, which AM has been for quite a while now, where you can use AM without any coding. No code here means no AM code. Doesn’t mean no code at all, because of course Headless involves a lot of coding. But there is no AM code required to get going with AM Headless, and you can pretty much use it out of the box just like you could, again, any other Headless content management system. But then very importantly in those conversations, to also make sure that everyone in the audience in your conversations knows that AM is, of course, more than Headless. While it can be Headless, and while it can be as Headless as you want it to be, AM is a lot more than Headless, and you can support single-page applications and traditional web pages with AM as well. And most importantly, you can mix and match. And we’ll talk about how AM is more than Headless later in the presentation. But let’s start with Headless itself. As a proof point that we wanted to share with you, and you can also use that for your conversations with peers and partners, is a implementation of AM in a completely Headless manner at Adobe, where Creative Cloud content and Creative Cloud endpoints on Adobe.com, but also way beyond Adobe.com, with traditional and very non-traditional endpoints, is being served with AM running in a completely Headless fashion. There’s no custom code. These users don’t even have access to GitHub repositories and so forth. They use AM. Pretty much, they used the way how they used another Headless content management system prior to that for these use cases, to now manage tens of thousands of content fragments, of which about 3,000 to 4,000 are original content, and then the rest is language copies, so translated versions and variations of these original content fragments, based on a little bit over 300 content models. And that is the first premise of AM Headless, that there are content models, which essentially are schemas to define the structure of your content, and which, in this case here with Adobe.com Creative Content, can be quite deeply nested. This new capability that we added earlier this year, where content models and then instantiations of these models as fragments, can be nested, can be deeply nested, if you wish. And with this nesting, you can really implement custom content structures by breaking content models into more atomic substructures using this nesting capability. And there’s more than 100 authors worldwide creating and updating this content. And it’s very different from page content, really. It’s like you see on the right here. It’s just like these little snippets of text with images, small pieces of text with an image. They get updated very frequently. They also get retranslated in a fairly synchronous and immediate manner, quite different from web page translation. And then from a delivery point of view, most importantly, because that is one of the biggest and most interesting challenges with Headless, because you have the delivery basically in two phases. One is the content delivered by the CMS through the CDN and the client, and then the client delivering the experience to the end user. AM is currently running in internal tests up into the tens of thousands requests per second on the Fastly CDN, which AM comes bundled with, with a cache hit rate of easily in the 99.8%, 99.9% ratio. And so this is pretty heavy. This is very heavy Headless use. And this is just to show that AM can absolutely scale for those kinds of use cases on that kind of level using AM as a cloud service. So we’re very happy with that implementation. And you can see on the slides here that it starts with the content model and the content fragment on the left. The experiences are on the right, which can be traditional web experiences, as well as non-traditional experiences, such as in-app messaging, for example. And the connection between the two is content delivery API, which in case of AM is a GraphQL API, which AM also comes with since early of this year. In January or so, we released GraphQL for AM, first for cloud service. And then in fact, just a few weeks ago for AM 6.5 Service Pack 10, also for the traditional deployment models. So all of these new content fragment capabilities, as well as GraphQL API, are available for AM 6.5 as well. So a lot of possibilities there. And in a quick demo, I wanted to show you what this looks like and how this works. And let me switch over to a browser. Before, after that, we’re going to look a little bit into how to set it up and some best practices, how to make it all work well. But when it comes to this mixture of traditional and non-traditional endpoints, one endpoint, for example, that we’re supporting with AM Headless is here in adobe.com, the Creative Cloud page. And it really looks and feels like a page. But in the logged-in experience, what’s actually loading, this is not a page. And this is probably very common to many corporate websites these days, where things kind of look like a page. They don’t quite feel like a page anymore. They definitely aren’t a page. So this here is a React application. And you can see up here, there’s apps, and there’s files, and there’s a Discover tab. These are all React content in adobe.com. And adobe.com itself, by the way, is, of course, still managed by AM, driven by AM. And the majority of it, the traditional way, with regular pages and components. But you can see how smoothly and tightly integrated this Headless content can be in such a website. And yeah, so here, apps, for example, that app catalog, this is one content fragment here, for example, that nests down into multiple fragments for each and every one of these tiles. And the whole point of implementing it this way is really content reuse. So that content, as well as experiences, can be reused. Because if you look at the client, the desktop application for Creative Cloud, which you might have on your desktops as well, if you’re using Creative Cloud, you see similar patterns here with the Apps tab and a Discover tab. And this is similar to the web page here. And here, you basically see the same fragments being served up in this desktop application, which essentially is a React app as well, just in a different shell, than here in the web page. And then, of course, there’s a mobile application. But then it goes even beyond that, if you look into Photoshop, for example, or literally any other of the creative applications. If you look at the What’s New content, these model UIs here, the teams there, they call them tostels, with the content that is served up in these tabs here. This is all served by AEM live through Fastly CDN, of course, heavily cached, including, here’s a video content, heavily cached. These desktop application clients, they have significant TTLs. I believe it’s like 72-hour TTL on these clients here. So everything that you see served up here is pretty much present in the client. But on the web clients, for example, the TTLs are completely different. And that’s a bit of headless, the beauty of headless in the decoupled model, is that you can control your cache parameters and your TTLs differently based on different clients and different requirements of your endpoints. And what this looks like in AEM, the way how it’s delivered, if we click backwards, is you see here, for example, a GraphQL query. So this is AEM, the GraphQL query editor that is built into AEM. And if we look at this What’s New tab here and the response to this GraphQL query, you can kind of see how this content here that is served in the JSON responds to the respective client. It starts showing up here. So here’s sky replacement. What does the text here say? We’ve added new skies. Is that here somewhere? Well, it should be there. But you get the idea. So this is how this pure content, this text content, is served into the application to then be merged with the design and the layout that is determined by the client, in this case, and not the back end, to form this experience. And in AEM, then, in AEM, these What’s New fragments, they are regular content fragments, just like you probably work with AEM and you know content fragments. And you see here, there’s a large number. Well, some of these 3,000 original content fragments, including here all the language copies, which makes it up to like 30,000 in total. And if you look at one of these fragments that we looked at here, and we’ve got to make sure we pick the right one. Because as you can tell, this is all in preparation already for Max 2021, which is happening in just a few weeks. And that content is already in our system. And of course, this is all under NDA. So we’re going to make sure I picked the wrong one and pre-announced some news that are coming on Photoshop. Photoshop puts new Max 2020. So let’s look at this one. And even though this developer conference wanted to highlight this, this is all UI-based. Working with all of this content here for the content fragments, and then as we click into the model, you’ll see two. This is all UI-based, where authors here can fill their content into these form fields of a content fragment. And with this new nested feature of content models and content fragments, they can take advantage of the structure tree in the fragment editor to manage the content further down in the hierarchy of their nested content structure. So here for this What’s New? Total, Toastal, we again see here sky replacement. So this corresponds again with this invite to edit sky replacement, save a copy, and so forth. That is all these structures that we just looked at here. So Toastal, What’s New, Toastal Pages here, What’s New, Learn More, Photoshop and iPad, and so forth. And users can then click themselves down into these sub-fragments. And you see there’s a little breadcrumb up here on top to enter their content here into this sub-fragment. And the overall structure of parent with a child fragments will then get published and served up as a JSON response to GraphQL request. And all this based on a content model. So that’s new in the fragment editor. Let me just show this again. Here in the fragment editor, we’re now showing which model a fragment is based upon. And you can click right here in the fragment editor. And you’re being taken to the content fragment model editor with the schema. The content model is defined. And whereas a model editor, you can add fields to your model in order to update the schema. We just added a feature a month ago to lock these models down once they’re published. So they’ve been automatically turned in a read-only mode once they’re published to prevent unintended edits in a published content fragment model, which might be used in GraphQL queries already. But you see here there’s a fairly significant number of content data types that were added earlier this year to help you create a lot more complex content structures than what was possible in years prior with AEM, such as fragment references for nested content fragments, child fragment reference. That essentially points the model to a folder, which then automatically pulls all the fragments in that folder into the editor, sort of like a list component. And that way, you can model things like a playlist, for example, or something like that, native JSON object. You can even add decorative elements with a tab placeholder to a model so that in the editor, then, there will be tabs appearing here to render certain elements out under tabs. That is the new tab placeholder data type. It’s not really data type. It’s really for decoration and for structuring the content in the model as well as in the fragment editor. So a lot of capabilities that were added this year. And again, all of this now available in cloud service as well as AEM 6.5 with Service Pack 10. And with that, let me switch back to the slides. And let’s talk a little bit about a couple of best practices and how to get started with this functionality. Basics for those of you who might have been involved with this for a long time. But we see it over and over when users are new that sometimes certain steps of those here are being forgotten. And then there’s the surprise that my models aren’t showing up for creating content fragments and all my fragments aren’t showing up in the GraphQL queries. So the first step that’s really important is to create a config, meaning basically a tenant in AEM in this UI here in Tools General. And in this config then, which corresponds with a JCR slash conf structure, that’s where you create your content fragment models then later. And then secondly, with a new UI that was added in around April this year, you also create your endpoints. So right in the very beginning of the year, all we had was a global endpoint. Now we have a UI to create custom endpoints. Typically, we would think they are a tenant-specific endpoints. And you can also secure these endpoints with permissions as you see fit so that not every user across different tenants can use everyone’s endpoints so that the endpoints get locked down to the content and the users they’re actually meant for. And then, of course, on the asset side, when it comes to authoring, it’s a standard pattern. You create a folder to put in your fragments. But quite importantly, ideally right from the beginning, you know, just create a language root folder. If you need to translate anyway, but even if you don’t need to translate right away, just put everything under an EN folder for English content or whatever your source language is. Spanish is your source language, and you make it ES. So that later on, as you create more languages, meaning other folders with ISO names, so that AM can use its content translation or translation management capabilities to find the source content and manage the translation into other languages. This is all driven by ISO codes on a note in your content structure, pages and sites or folders and assets. And then very importantly, this is a step that quite often gets forgotten. Once you’re at this final state and you’re just itching to start creating content fragments in that folder, you got to make sure that in the advanced properties of that folder, you assign, you add that the config up here to the folder. That is what will make the models that you defined in that config appear in that folder for fragment authoring. And on these folders, I didn’t list it here, but there’s actually more capabilities that you can define, such as permissions on the folder, so that only certain users have access to these folders. Or what you can define is model policies on folders. So that in certain folders, only fragments based on certain models can be created. So that’s a way how we wanted to help create some governance rules that allows users to work only some users in some folders and other users in other folders for their specific tasks. Then there’s just a producer creating content fragments and referencing assets. And very importantly then, more to the heart of our topics is the developer conference, creating queries. For creating queries, it’s very important that we keep in mind is that AM supports persistent queries. And we’ll talk about it in the following slides. So you can request GraphQL queries with AM using post requests, but we strongly discourage that because it’s bad for clients and it’s bad for the origin. But really encourage using persistent queries that can be saved in AM, persisted in AM, and that your client application can then request for the GET request, which makes the query and its JSON response cacheable. Beautiful for the origin, beautiful for the client. And to help you do that in your client application, do keep in mind there are SDKs available that help them make it easier to list all persistent queries that are available in AM to request certain persistent queries. There are patterns available for JavaScript, for Java, and for Node.js in SDKs under this link here. I just linked the JavaScript one, but there are further links to the Java and the Node SDKs as well. When it comes to best practices for creating this content and for using content fragment models and queries, one thing we found works pretty well across not just external customers, but also Adobe internal stakeholders using AM, is when you get started creating your content structure, really look at the resulting experience first, almost like a mock-up of a web page in years prior, and then start modeling the structure of your content based on the components and elements of that experience so that your model then starts reflecting what is the teaser, what is the header, what is the footer, what does the product offer, what is the click to action, what is the pricing detail, for example, what is the disclaimer at the bottom. This will make it easier later on with your authors to discuss what the different elements and fields are in the fragment editor so that they know what to enter in the fragment editor form fields. But then, as always with AM, the sky’s the limit. You can create as many models as you want, just like previously or currently still. Of course, when you author pages, you can create as many components as you want. But for everyone who’s been with AM for a little while, the fewer the better. The fewer components, the better for pages. And the same is true for headless content management as well. The fewer models, the better. It’s not so much a performance concern, but more of a governance concern to help keep an overview of what’s going on. And that is also true for that levels of nesting. The deeper these nesting structures go for custom structures, the more difficult it will be to keep track on what is nesting what. And when you publish these structures to make sure that all of the child fragments and their children and their children and children are being published as well, the deeper that gets, the more complex it gets. We found that max five levels, this helps, I mean, definitely model custom structures. In those Creative Cloud experiences, we have a couple of models that go 20 levels deep, which is borderline crazy. But it works in the system. And it shows that AM is very scalable there. So it’s not that the system breaks down or that performance issues start materializing. But it just gets really unwieldy. So just watch that. When it comes to fragments themselves, again, here also, keep in mind the folder structure. Start with a language folder. But then also, just like with models, keep it simple. As simple as possible, it’s just going to make it easier to manage the content as your experiences grow. And quite importantly, with AM, kind of a general thing with AM, but with headless in particular, because it’s decoupled from the front end, be careful with moving and renaming folders and fragments. Anything that changes paths requires that all references or all queries, for example, that use certain paths are being updated. References, AM takes care of on its own. So just like with pages, if you change page references and you move a page, and the reference get adjusted. But it just imposes the risk that some of these reference adjustments might go sideways. And the same is true with fragments. And when it comes to queries, queries don’t automatically update if you move a reference and you forget to republish, for example. So be quite careful with moving and renaming. And I think I actually have a slide after that, just to bring it up one more time. For translation, also, do keep in mind, so content fragments can be translated just like pages. The same out-of-the-box translation management capabilities with integrations to translation ISV systems are available for AM. And when you translate your content fragments, just like when you translate pages, do keep in mind, there’s different ways how to use AM translation integration. You can use it via the admin UI, where you create language copies, create translation projects. Within those projects, you create translation jobs. Or you can do it directly in the projects UI. You can create new translation projects in the projects UI and then add content fragments there to initiate translation. Very importantly, and those are the most important parts you wanted to highlight, really, again, as mentioned before, do use persistent queries. It’s a feature that AM has. And it just makes these queries cacheable. Makes the JSON response cacheable. And just altogether makes it a lot easier to work with that content. And because of the challenges potentially by moving content, be careful with bypass queries. And what I mean with that, let me go to this slide here first. Here, for example, is a bypass GraphQL query. So that is possible. You can request individual fragments with such a query here, where you can get a response for only that one particular fragment for a person called Jane Lee. But again, if that fragment happens to be moved in AM and that query doesn’t get updated, then the query will break. But do keep in mind is they can build pretty much the same kind of a query and get the same JSON response by using a general list query and then filtering for first name Jane, could have add filter for last name Lee here as well, to pretty much get the same JSON response. And as you can imagine, this query down here, that is independent of the path. So there’s different ways how to not be too dependent on paths. And just always keep an eye on that. One quick word again back to persistent queries. Not only are they cacheable, very important. You see here’s how you persist a query with a command line editor, with curl command. But you can also pass, or you can use Postman collections. We are working on a UI to make that GUI enabled as well. But currently, it’s command line editor or Postman. But you can also pass cache control parameters from AM to your clients, where this cache control parameter here, for example, turns into an HTTP header as such down here at the bottom. So very important to keep persistent queries in mind when you work with AM Atlas. And lastly, again, as mentioned in the beginning, keep in mind that there’s a lot in AM beyond headless. I mean, you can use AM headlessly if you wish. But headless is not an end of state. It should not be a technology-based decision to use AM headlessly. It should be based on business requirements. And rather focus on your business requirements. And if some is headless, that’s great. And if other use cases require other methods for your content, that is just fine. To, for example, also keep the marketing user, the line of business user who author content included in the equation. All too often with pure headless, those users get left out. And for pure content updates, those users then have to go run to IT to request content updates or layout updates. And do keep in mind that with AM, while headless is completely possible now, you can also have a headless SPA that is managed by AM with the SPA editor in order to implement basically a hybrid pattern for decoupled delivery. And that can be mixed and matched with traditional delivery as well, where AM components that typically generate HTML on the server can also export JSON that can be used in these headless endpoints. So there’s many ways how to mix and match headless with traditional. Either one can be used standalone only by itself, or they can be mixed and matched. With that, I just wanted to click to the end to remind us again. So keep in mind AM is absolutely headless. If you want to use it just headlessly, absolutely possible. But it is a lot more than headless. That concludes our session about AM sites and headless. Wanted to point everyone back to Experience League, which is a great resource for community and for more information about AM. Specifically, for any questions that might have gotten unanswered in the chat, there’s a forum specifically for the session here. So do go to this link here to continue the discussion of AM Headless from the session here. And last but not least, if nothing else from this presentation, do keep in mind you can win something. If you go to Experience League Communities, you can win some great Adobe Chachkis or a backpack. And if you go here, then you can add yourself to these raffles. So with that, thanks for listening through. Hope you found it interesting. And I wish you a great rest of the Developer Live conference. Thanks.