Experience Manager Extension for PWA Studio

Transcript

So good morning, good afternoon, good evening, and welcome to this session about Experience Manager extension for PWA Studio. My name is Martin Bjorgi, and I’m a product manager for the Experience Manager responsible for the Commerce Integration Framework or CIF. If you’re not familiar with CIF, it’s an add-on for the Experience Manager that extends its site’s functionality with commerce authoring capabilities. This helps our customers to break down the silos between content and commerce. And with commerce, I mean seamless online shopping, which is usually owned by the merchant. And with content, I’m talking about marketing experiences that is usually owned by marketing. So the goal of CIF is to create immersive commerce experiences that are also shoppable with the goal to positively impact sales. With me co-presenting is Mark Becker, senior engineer in the CIF team and also lead architect of this PWA extension. And we split the session in two parts, where I will set the stage and also do a short demo of the integration before I hand it then over to Mark for the developer portion. If you have any questions, just add them to the chat, and we’ll take them as we go through the presentation. So for this session, we have prepared three great takeaways for you. The first one may be a repetition for some of you. We will learn, or you will learn, about all the various options you get with AM to build headless content and commerce experiences. Then you learn how you can enrich the PWA studio with AM content to create shoppable experiences or immersive experiences. And lastly, you will have a better understanding of which headless architectural will work best for your project. And with that, let’s start with a quick overview on the various headless options in AM. For commerce, headless is, by the way, pretty simple. All services and data are exposed via the GraphQL API layer of commerce. So we always use the API to consume that data. For AM content, you have two options. Option one is what you see here, and it’s what we usually refer as the headless CMS use case, or also sometimes referred to as form-based content. In AM, we leverage content fragments for that. You create a content fragment model, so it’s very structured content. And then you create the content fragments by using a form-based editor in AM that really follows the content fragment models. And as an author, that’s the big difference here, is you cannot influence the look and feel. You’re bound to the editor. You just fill in the pure content. This is super efficient, and it works great if you have repetitive, structured content where layout and design is given. A great example is a blog, for example, where usually all the blog entries looks the same. They follow the same pattern and the same data model. The other option is the page and component-based approach, where authors use AM’s editor to create experiences by dragging drop components on a page, and they also lay out the page. So it’s the whole WYSIWYG approach, where you always have a live view of how the experience will look like. And that option is great for use cases where you want to drive and own the layout, or when it’s a one-off where implementing a whole content fragment model is just too much work. Great example here, a landing page, or also if you think about any promotional or micro page. Now that we know both types of content in AM, let’s see the various ways how Touchpoint can consume that content. Let’s start with the pure headless AM deployment, where a Touchpoint consumes the content fragment’s JSON data using AM’s GraphQL API. The Touchpoint, and you see here three examples. Let’s take Spi as an example, is then responsible for the whole presentation. The next option is what we call hybrid delivery, where the Touchpoint consumes page and component-based content. The content is still delivered as JSON using AM’s content service, but we call it hybrid because AM also provides layout information. And the Touchpoint, the Spi, will then use that layout information to render the experience. So they both share the rendering. The last deployment model is the traditional approach, where AM consumes headless commerce data, but then it renders the whole experience before it gets then delivered to the Touchpoint, also referred as server-side rendering. And as usual, there is no one-fit-all approach. The right deployment model depends on your use case and your requirements. And I love challenging my customers. What are the urgent challenges you need to solve now? And also, what is the vision? Where do you want to be in five years? And if you have a good understanding of short-term and long-term, then you can better figure out what technology is a better fit, whether you want to go headless, hybrid, or coupled. And also, think of all the other questions, like is the technology really be very agile with that technology? Do you prevent any bottleneck, developer bottleneck here? And that all depends also a little bit on your organization or the skill set of your engineers. If you’re already an existing AM customer, I think it also makes sense to evaluate if the effort to switch over to headless hybrid justifies then the value that you will get with moving over. But in any event, the good news is whether you go with headless, hybrid, or coupled, we have you covered. We have a blueprint to kickstart and accelerate your project. For customers looking to build the pure PWA, we recommend using PWA Studio. And that comes with its great set of developer tools. If you aren’t sure or not ready for a PWA, you can also start with the AM storefront, which is best of web and headless approach. It comes with all the great stuff you know from AM, such as core components, but also combines PWA elements like client side React JS components. But we have another session that will cover this storefront. In our session here, we focus on the PWA Studio in a pure AM headless deployment scenario, which is also my segue now into the AM extension we want to talk about. And on the left side in the green color, you get a no review of all the various elements we’re going to show you today. And before I jump into the demo, let’s have a quick look at these elements. And we start with the AM extension for PWA Studio. And that extension extends the PWA with a second endpoint. The first endpoint, that’s what you need to consume commerce data. The second endpoint is then to consume content coming from AM. And the great thing is this works out of the box with AM. It does not require any customization. We simply use standard functionality in AM, the content friends I mentioned before, and the AM GraphQL API to consume the data. We also provide two examples as a guidance for your project. One example, as you will see, is a pure content page. And the other example is where we enrich an existing commerce page with content coming from AM. On the authoring level, we leverage the SIF, or the Commerce Ingratiation Framework, add-on to increase author productivity. Because in most cases, marketers want to decorate product data with additional marketing content. Think of additional assets such as PDFs, videos, or also think about all the additional marketing properties that you want to manage. And as a marketer, you usually want to manage these kind of assets or that data in AM and not the commerce engine. We also call this discipline product experience management. And as I said, SIF is here, the right add-on to do that in a very efficient way with all the tools. The integration with the PWA extension itself does not require SIF, but we strongly recommend to use it also because it just comes for free for AM and commerce customers. And as I said, it has a lot of great tools to make a marketer’s life easier. And with that, let me switch now in a short demo. I’ll show you how the AM extension works before I hand it over to Mark. And the first thing what I’ve done is I have here the out-of-the-box Venya example. And as you can see, that’s one great thing of a PWA. I was able to easily install it here on my desktop here. And the first example I’m going to show you is a pure content page. Here it’s a blog. So we extended the menu with a blog. And as you can see here, we have a few blog entries. If I click on a blog, then I get all the details. And that is content coming 100% from AM. So let me open up here the experience manager. And I’ll show you how we have built that. And as I said, this is a pure vanilla installation with SIF installed. So the first thing I’ve done is I installed or I created content fragment models. So here for that use case, I have a model for an author because authors, once I create an author, then it’s a one-to-one relationship between an author and multiple blog entries. So as you can see, it’s a WYSIWYG editor. I just drag and drop all these text fields on it with the typical things you want to know about an author. And the other example is then here the blog post itself. And as you can see, same thing here. I drag and drop the model together. Maybe what I can refer or highlight here is published by. So that’s where I reference to another fragment. And if you look at the properties here, I can even say only author fragment types are allowed here. So that’s the model I created. Then here under AM assets, I created content fragments for authors. So if you click on author, then we have here the examples. And it doesn’t matter how you organize these fragments. I just preferred a logical way in authors and blog entries. So here I have all the information about the two blockers. And the blog post itself, I created also folders here. And I’ll have here prepared a new post here for cycling in Tuscany. So first of all, if I click on the blog, then you see that’s the form based. I super fast just entering the data. I don’t have to focus on anything else. Once I’ve entered all the information, the only thing I have to do is I’ll do a quick publish from the authoring environment to the publish environment. And if that is done, then we can go over to the example. And let me see. Hey, Martin. While that loads, we did have one question come in. Yeah. Is AEM free for commerce users? No. AEM is a separate license that you have to acquire. Thank you. But AEM works with Magento version, even open source version with limited functionality. But we obviously recommend to use Magento Enterprise. So I’m not sure this is usually that happens just in demos. Let me see if it works, if it still works, if it’s just a UI issue. And what I have to do is I have to clear the cache, the cookies, because the PWA caches all these things. In real life scenarios, you would use then service worker to notify that content updates are available, or you just update the content here. So let me see if that has worked. It obviously did not work. But what we would see here is it would just show then the additional block entry. It might be an issue with my publish instance. So I mean, you understand the principle. I’ll just add the fragment. It will then pop up here. So let’s see if the second example works or if the demo gods have left me for good. The other example I want to show you is how I can enrich an existing PWA page. And so with PWA Studio, what you get out of the box is a product catalog. It might work now. It was a bit slow, just to make sure I didn’t lie to you, unless there was just a timeout. Here, see? So I got this cycling Tuscany here. So the next example, as I come back here, this is the default product detail page. So the PWA requests the product data to render that. And the typical use case for marketers is that they want to embellish content, add additional content here, and maybe even overwrite the title because it’s not fancy enough. So what I’ve done in AIM is I just created another content fragment model. And here, what I have is a title and some text. We just focused on this one here. So you see it’s a bit more fancy, the title. And I also have additional text that now I, as an author in AIM, can own. Now, what I have to do is I have to connect this content fragment with product data. And that’s where CIF comes in place because we have now additional commerce-related content fragment types. So I have here this product content type. And I can now find the right product here. And as you can see, I have a live view to my product catalog. So I don’t have to swivel chair between AIM and Magento. I have everything that I need directly in my UI. And that allows me to work now super efficient. So I just make the connection between that product and that content fragment. So I’ll save it. And I publish that as well. And if I now clear quickly the cache here and then refresh the page, what you will see in the example is, first of all, here it loaded from AIM the additional marketing content. And here we’ve extended the component that it will override if the content fragment is available. So that’s just a short demo of what you get out of the box. And now I’ll hand it over to Marc for the engineering portion of this session. All right, thanks, Martin. Let me quickly take over the screen share. All right, so as Martin said, let’s take a deep dive into the concept and technical details of that demo. So Martin was referring to AIM content fragments. And I would like to give you a bit more details on how they actually work. So as Martin said, content fragments are a form of structured data, which means they are both presentation agnostic and reusable. So unlike other forms of content in AIM, like experience fragments or pages, they do not contain any layout or style, just pure data. The structure itself, it’s fully customizable and based on a model, which you can design yourself. And you can actually see an example here on the slide on the left. And when designing your content fragment model, you can choose among different data types, simple ones like text, numbers, booleans, and also references to other AIM content like text or other content fragment models. That’s what Martin showed you when he mentioned that we have an author model and a blog post model, and both are linked using content fragment model references. If you use the CF add-on for cloud service, you will get additional data types that let you add references to product and category data coming from Adobe Commerce to your content fragments. In the PDP extension, as Martin showed, we actually use this feature to add product references to content fragments. With this reference, we can actually do a reverse lookup to find all content fragments which are assigned to a specific product, and then on the product page, basically do an overlay of the content. Once you have defined the structure via the model, you can then use the model to create actual content fragments like blog posts or other product page extensions. Content fragments can be consumed in many ways. For example, there are the AIM core components which have components to display the data from content fragments. And for headless integrations, you can consume them using GraphQL APIs. If you’re not familiar with GraphQL, it’s basically a way of designing APIs which lets you specify exactly which portion of data you want to request. The second important feature here is introspection, and this means that the API exposes its own structure and documents itself. So the actual schema of your GraphQL API here is automatically generated based on the structure of your content fragment models. And since in most cases, these models will be fully custom and based on your use cases, the automatically generated structure will also be fully documented using the before-mentioned GraphQL introspection feature. What you can see on the slide here is actually how this looks like. This schema is generated based on the content fragment models, which are included in the PWA Studio extensions. And what you have here are two queries for each model and one query which you can use to look up an individual content fragment by path and one which you can use to list a number of content fragments based on certain filters. OK, let’s talk a bit about Magento or Adobe Commerce PWA Studio, which we used to bootstrap the Vigna storefront you just saw in the demo. So with PWA Studio, you can build your own storefront as progressive web app or PWA. And with the included Vigna template, you can have a fully functional running storefront up in seconds. As the name suggests, PWA Studio seamlessly integrates with Adobe Commerce and Magento open source and communicates headless using GraphQL. And in general terms, PWA Studio is a collection of tooling, React components, templates, and much more, which help you build a feature-rich and high-perform online store. And there are actually multiple ways of how you can get started. The easiest way to start is using the Vigna template and then use the powerful extensibility framework to additionally customize and style the store to your needs. And we actually used the very same framework for the demo you just saw. And I will go into more details on that in a second. So talking about the actual PWA Studio extensions which we built, so they are basically there to kickstart your AEM headless integration. And to basically first give you a showcase and a working example on how to enrich your storefront with marketing data that’s coming from AEM. To do this, the extension contains multiple things to get you started. So we have some sample content, meaning content-focused models and data for blog posts, authors, and the PDP extension. We have some configurations which help you to enable the GraphQL endpoint in AEM and also to make it accessible from your PWA Studio project. We then have React components which can actually query the data via GraphQL and render it. And we have some additional PWA Studio customizations using the extensibility framework to basically bring everything together. And I highly encourage you to have a look at that. The extensions are available on GitHub. And you can find the links at the end of the slides. OK, so as I mentioned earlier, PWA Studio integrates with Adobe Commerce using GraphQL and using the GraphQL endpoint that is provided by Adobe Commerce. The question is now, as we mentioned earlier, how do we introduce the second GraphQL endpoint, in particular the one that’s provided by AEM into the mix? So internally, PWA Studio uses the Apollo GraphQL client for React to allow any React components to make GraphQL calls to the backend API. And what we did is we customized the GraphQL client configuration, in particular the Apollo link configuration, to add the AEM content fragment GraphQL API as a second endpoint. And then the decision to which endpoint a query is actually sent is done using a target attribute, which each component can pass as part of the query context. If the target attribute is AEM, the query will be sent to AEM. Otherwise, it will be sent to Adobe Commerce. And the default behavior here is important. This is basically to stay compatible with all the components that are out of the box included in PWA Studio. So usually what you would do is using this target attribute for the components which are first included in the extensions, and also the ones you would additionally create to render marketing data from AEM. OK. Let’s also have a brief look at the extension mechanisms PWA Studio provides. The first mechanism I want to talk about is called targets. So targets are extension points that are used for common customization use cases that are well-defined. And you can also consider them public API. They allow you to intercept and extend particular functionality. In the extensions, we use this mechanism to declare additional configuration parameters, like the AEM GraphQL endpoint, but also adding custom routes for the routing in the PWA Studio app, for example, adding the block section route to the PWA. So whenever a user goes to the slash block route, the PWA Studio then knows how to render this route, by then displaying the block index page component, which is also part of the extension. A second mechanism is called targetables. They basically allow you to change any piece of source code of PWA Studio, and in particular, any piece of source code that is present in any of the dependencies. The most important dependencies to mention here are the two main layers PWA Studio is built with. So you have ParaQueen, which provides basically the generic logic, and you have Vigna UI, which adds then the Vigna look and feel as you saw in the demo. On the slide here, you can see an example how you would apply these kind of customizations. One thing I would like to highlight is, please be aware. In comparison to targetables, since they work on source code, and source code is not considered API here, any customization you might or you will apply might break when using or when upgrading to a newer release of PWA Studio. So please use this very carefully. There are also some security limitations here. For example, extensions, like the one we built, are not allowed to apply these customizations directly. However, we provide some functions in which you can call in your project that apply these customizations for you. As you can see on the slide, one of the use cases we use this pattern for is to extend the navigation component to actually add a block button that directs the user to the block section. The other use case where we use this is to basically extend the product detail page component to fetch additional data from AEM to basically overlay the data. All right. So now that you have seen how the PWA Studio extension work, let’s take a step back and see if this is actually the right fit for your project. So what I have shown you today is the Apollo routing pattern. This is well suited for projects which you want to enrich with smaller portions of content, or in particular, structured content. And all sources of content need to provide the CraftBL API. And as you could see, you can implement this kind of integration very quickly. It’s high-performance and does not introduce any kind of latency. The major downside here, however, is that the complexity increases for every additional background, meaning for every additional CraftBL endpoint you introduce, and also for every additional client or touchpoint you introduce. So every change to the environment requires to update every one of your clients and touchpoints. A common alternative for more complex environment is the back-end for front-end pattern. You basically add a service in between all of your clients and all the back-ends, and which can then federate multiple CraftBL APIs, or also non-CraftBL APIs, into a single endpoint. And if you do this, all of your clients need to know only about a single endpoint. And having this routing logic in a single point simplifies the implementation logic of your clients and touchpoints. But on the other hand, it introduces additional complexity, since you’re adding another service. And a third architecture, which Martin also mentioned, involves the AEM in Russell editor, or previously known as Spy editor. This one does not work with CraftBL, but it gives you a full control over the page layout and hierarchy, so you’re not limited to only smaller portions of content. And as you notice from AEM, you will also get in-context editing. The major downside here is that you have to build your own PWA using the libraries the Russell editor provides. All right, so I hope this could give you an overview of how you can build your headless integrations with AEM. And this concludes the session. Thank you. Everything we mentioned in the session, you can find here on the slide. And if you have any questions, we are still here to answer them. Thank you.