How to Build Content and Commerce Experiences Using App Builder and API Mesh

Transcript

Welcome. Thank you for joining the session about AEM headless content and commerce. In this session, we will guide you to the end-to-end tasks and workflows you typically work through if you build an headless e-commerce experience and building out your own website. Speaking about we, so we are James who’s with me from the AEM Adobe Commerce team. Mark Becker is with me from AEM Science and Commerce team and my name is Marcus Hark. I’m from the AEM Science and AEM Commerce team as well. So the topics we would like to address, so are basically the typical challenges a developer goes through when building an e-commerce experience. First is what are the topics David would actually like to build. So the goal is you want to have maybe already experience, you have your marketing website and you want to make the entire site transactional. You want to add e-commerce content to your site, creating PDPs and PDPs and making the entire experience shop including commerce transactions, adding checkout flow, shopping cart, my account pages as well. From your business owners and your product owners in the project you get always the pressure, hey this needs to be done quickly, we need to have this feature out quickly on the website and we will address these topics as well and show you how we can really with a quick turnaround and very smooth developer workflow can address these needs. And last but not least, data. As a front-end developer you most likely not care that much about the back-end APIs, how they are built, how you work with these APIs, what are the characteristics of such an API and for that we have a solution as well which allows you to build your one API back-end for front-end for your front experience. So from the steps let’s start from the back-end to the front-end. So we guide you through the step-by-step end-to-end workflow. First we’ll start with defining our own back-end for front-end, defining our API using the Adobe API Mesh Builder. Second, Mark will guide you through the steps of bootstrapping your application, adding content and commerce to your headless website and making these applications shoppable. And last step number three, James will add all the stuff you need to build a full functional e-commerce applications by adding our new micro-front-ends for commerce, cards for commerce checkout flow to the existing application. And after you finish that step you are basically have your e-commerce site up and running and it’s ready to ship to your customers and set it live. So let’s start with the back-end. In most cases you don’t have only one API. You have multiple APIs you have to deal with as a front-end developer. That makes it cumbersome. You need to know about all the authentication. Maybe you have different throttling and different behavior. Some APIs might support a push model while others have a pull model. And to make the life easier for you as a front-end developer we have a solution which is called the API Mesh for Adobe Developer App Builder. Very long name so I will only use API Mesh in this presentation. What is it actually? So the API Mesh is a cloud service provided by Adobe which allows you to build your individual front-end APIs and design and configure your back-end for front-end for your custom application for any kind of application. It allows you to combine multiple APIs you have either if it’s Adobe APIs like we use in this presentation from AEM and Adobe Commerce can be third-party APIs like in e-commerce you might have a track and trace service you want to integrate or you have a dedicated API for inventory and it can be your custom in-house APIs you have built as part of the project as well. Additionally to the simple aggregation and combination of the APIs the Mesh allows you to change and modify these APIs and extend them either by configuration or by using App Builder extensions writing JavaScript as well. The data sources we will use in this presentation are all providing already your GraphQL API endpoint. So we have the GraphQL schema from AEM for the content fragments and we have the GraphQL schema for Adobe Commerce. But what happens if you don’t have GraphQL APIs? That’s also no problem. The API Mesh supports multiple different data sources which you can integrate to build our back-end for front-end. This can be an open API which is automatically then inspected and mapped to GraphQL schema and if you don’t have an open API it almost can be any API which can provide a JSON output as long as you have a JSON schema. Either the API already has a JSON schema linked to or you can provide this in a separate file and can then this to deploy together with the Mesh configuration. So as long as you can create a schema this API can integrate with the API Mesh. Once you have the data source configured and I will show that in a minute typically in many cases you want to do apply more transformation and changes on that schema. For example you might have deprecated methods you want to hide from the front-end user because you don’t want the users to use them. So you can filter these API portions from the schema, you can hide or hide and remove mutations and create from the schema, you can apply transformations like renaming, prefixing portions of the schema, etc. And the last but not least the real powerful feature of the API Mesh is the federation application which allows you to combine portions of one schema and merge that into another schema so that as an front-end developer the query gets super easy and instead of firing multiple queries you can retrieve objects from different data sources under the hood with just one query. What about building these Mesh configurations? Of course you can start on a plain green field and building your Mesh configuration from scratch but to make your life easier the API Mesh also includes the so-called source registry. The source registry is basically a library of templates for solutions Adobe provides and for these Adobe solutions you can already get a template, templated configuration, you can inspect that, can view that and if you like that and if it makes sense for your use case you can also get it and automatically integrate in your Mesh config and from there you can still start then adding your own configurations, extra data source, extra transformations to the Mesh config and deploy to the API Mesh. This gets extended over time, we have multiple sources already available and more and more data sources gets added to the API Mesh registry as well. So how do we actually work with the API Mesh? There are basically two options, first one you have seen in the screenshot before there is a CLI which is the Adobe AO CLI, the ones you might have been used before for example if you look at Google and this has an API Mesh plugin and with the plugin you can interact with the Mesh service. The second option is the developer console from Adobe which has an integration of the API Mesh as well and instead of speaking about this in mid-theory I will switch to a demo and show you this in real life. So let me first show the console. So what you see here I’m already logged in into the developer console, I have my project ready which I use for this demo and in that project I already can see I have an API configured for the API Mesh. I have two products, it’s the API Mesh in general and it’s my Mesh configuration and if I go to my Mesh configuration I can also see the configuration, I don’t go through in details yet at the moment I show this to you in a second in my IDE. I have my Mesh ID and I have a Mesh URL which I can then use later to actually really interact with the API. This is the URL which you hand out to your developer for the developers and they can use this API to work with the Mesh. So how does the Mesh configuration look like? For that I’m switching to my IDE. I’m first checking if I’m really working with my project and getting my Mesh configuration. And yep this is my project, I have my Mesh ID, I have the endpoint here as well. So let’s quickly look into the Mesh configuration. And in the Mesh configuration I first defined a few headers, in this case we disabled cores to make it easier and to have it local better or easier for local testing. Then the most important part are my data sources. I have defined three data sources in the sample Mesh configuration and you will see how they are working together in a second. So I first defined my data sources for Adobe Commerce which links to my Commerce environment to the graphical endpoint, the graphical data source. Second data source I defined is for AEM which links to my AEM graphical endpoint providing all of my content fragments and my content fragment models. And the third data source is in public available graphical endpoint which I just used here for a demonstration which provides me a list of countries and for each countries that can get details like the capital and some other funny things just to have the example of a non-Adobe API integrated as well. And as I said I can apply different transformations to my final graph girl schema and I show this to you here. I apply two transformations for my AEM graphical schema. So the graphical schema from AEM will be first prefixed with AEM underscore. This is more for illustration but it’s also handy for developers who can easily distinguish which part of the schema are provided by AEM and which parts of the schema are provided by other data sources. And I filter my schema. I removed one query type which I don’t need for my project. It’s still in the original schema provided by AEM but it’s deprecated and I don’t want to use this and expose this to my end users. So I can easily filter everything which starts with product marketing data model which I think is three or four queries I have and they all get filtered out. For the external provided service I do a small transformation as well which is a rename. And the reason for that is the Adobe Commerce schema already provides a query which is called country and to don’t confuse my users I simply renamed this one from the external service to country version 2. So I have can clearly distinguish my name between the one which is coming from Adobe Commerce and which is coming from my external service. And if I’m happy with my configuration I can use my CLI again to push the configuration to the API mesh. Update and I provide my mesh configuration. And it asks me if I’m really sure what I’m doing and I want to push that which is yes and then I push that configuration. And with that we are done. So let’s try it out. Switching back to my browser I have my GraphQL client here. To be sure I’m using the right API I again copy my mesh URL here and put it in but it should be the same. And let’s load the docs here. And that’s first inspecting a little bit the query the schema. The schema is quite large because Adobe AM with the content fragments I have a few models in that schema. That’s quite a lot and Adobe Commerce also has quite large schema. So as you can see the first transformation all the parts of AM are prefixed with AM underscore. So I have my category models for extensions with those categories. If you scroll down a little bit there are more AM schemas and then portions of the schemas which you can use. And then we have the Adobe Commerce schemas portions which I didn’t touch. So all the queries we have with the commerce are basically represent here one to one. And for the country this is the one from the external service which is showing up in the schema as well. So the schema I closed that to have more space for doing some demo queries. And as you can see here now I have my mesh. In my mesh I can do multiple queries from different data sources. So I have the first part of this query is I’m creating for products and I filtered them by SKU which is coming from a variable which I closed here. So I have a variable which has one product SKU which I use here for the demo. And that variable is handed over to the products query to filter the product and it’s also handed over to a second query I am adding here in the same call for a content fragment. I can also filter my content fragments again fitted in by SKU and I’m retrieving data from AEM which I will add to the content. So let’s run that query, send in the request and make this a little bit bigger. So what we see as a result as expected we’re getting product data from Adobe Commerce and if we scroll below we get content fragment data including the path some data from the content fragment itself from AEM. All together I’m okay instead of working with different endpoints executing Kafka queries on different API URLs I can do this now all in one query super easy super cumbersome super easy not cumbersome and as a front end developer my life is way easier than dealing with individual APIs. And dealing with the APIs and using them in the front end application is now shown to you by Mark who will cover the part of building the front end application part. Mark over to you. All right thanks Marcus let me take over the screen share. Okay so I will continue with giving you a brief overview of CIF associated content and then how you can use both of them to enrich your storefront experience in headless applications. So to integrate AEM with Commerce we offer the Commerce Integration Framework or short CIF as add-on to AEM as a cloud service and also available for AEM 6.5. And this basically allows you to bring commerce data from your commerce engine into AEM. And as you might know CIF includes the traditional sling based AEM components like the CIF core components and storefront accelerators that are ideal for applications where AEM owns the delivery but you can also benefit from like powerful authoring capabilities within AEM when using CIF in a purely headless context. One major use case here which CIF enables is stability to enrich commerce data coming from your commerce engine or PIM with content coming from from AEM. And here CIF supports various types of content within AEM like assets, pages, experience and content fragments. And then these can be associated to product and category data. Some typical use cases we see in the field are for example adding promotional content like banners to catalog pages, adding additional photos, images, videos, brochures, manuals, pdfs to products which are then which and those are coming from AEM assets or also adding marketing focused product attributes like personal recommendations. And of course you can consume this associated content then via API for both headful and headless applications. To give you an example let’s go through a typical enrichment workflow using content fragments. So with headless you can actually apply similar implementation patterns like the ones we recommend for traditional AEM projects using CIF. So for large catalogs you can apply a dynamic catalog model where you do not create individual pages for every product or category but instead use like a generic template page which you fill with product data that is dynamically loaded based on your URL schema. So you have like a a product or category identifier in your URL which you use to load then the correct product or category. For more details on that I actually recommend you to have a look at the previous developer’s live session on enrichment which I have linked for you in the reference section at the end of the slides. So going back to what you see on the screen here. So you would start with the generic product page which then looks the same for every product in your catalog. Next you need to define some content let’s say some structured content in the form of a content fragment which you would like to add to your product page. This you would then need to connect to a product like creating the association and you can use the product data type in the content fragment model editor which is part of the CIF add-on. And then with this association in place you can then change the implementation of your product page to additionally load the content you just created based on the same product identifier you used to fetch the product data that’s coming from commerce. And of course the same or the very same applies to category or plp pages as well. So let’s talk about APIs and how what I’ve just told you comes together with the API mesh that Marco presented earlier. So if you now adapt the implementation of your product page you will have at least two queries. One query to fetch the product data from commerce and one query to fetch the content fragment from am. And also depending on your setup the queries will also have to be sent to two different endpoints. As Marco showed you with API mesh we can now combine both endpoints into a single one and also depending on the use case you can even combine the schema of both queries like you can see in the example here on the slide. So here on the slide you actually end up with just like a single query that combines both of those. And this helps you to streamline the developer experience and make it much easier to consume content and commerce via a single API that is first tailored to your project. But also additionally you have struck away the whole complexity of figuring out from which backend your data has to be fetched from. All right let’s jump into a quick demo where I show you the whole process end to end. First let’s prepare some content. Here I have already some content fragment models which you also saw in the schema that Marco showed. And these basically define the structure of some content which I can use to enrich my product page. So if you open the model here in read-only mode you can see I added a product reference field which is available when you have the CIF add-on installed which you can then use to associate the specific content fragment to a product. And there are also some other fields which we can use to enrich the product page. Now let’s go to the content fragment admin and create a new content fragment based on the model I just showed you. So we take the product page extension and I would like to create an extension for the Juno sweater product. Great. Fresh. So again the first field here you can see that’s the product reference coming from CIF and I can simply open the product picker and select the Juno sweater and then automatically there will be a reference added. With regard to the other fields, so we also have an asset field which I can use to define a banner that will be displayed at the top of the product page. Let’s just select an asset here. Then some kind of stylist comment. I can just say this is a nice sweater. And there’s also some kind of selection which you can then in your product page implementation use to define different stylings or variants of your product page. I can now save this. And also then publish this to make it available. And let’s have a quick look at the code. So I’m actually using just a very simple Next.js application as an example. And also you can find the source code in a repository that’s also linked in the references at the end of the slides. So when we actually then open a product page, since we’re using API Mesh, it’s sufficient to use like a single Apollo client that just points to the GraphQL endpoint that’s defined by our API Mesh. And if we have a look at our query you see something similar like what Marco showed you. We just have like a single query with one part that is fetching the product data from commerce and one part that fetches the content fragment coming from AEM. And this can be sent all in a single request to the Mesh endpoint. Okay, so if we have all of this in place, let’s also have a look how the actually enrichment looks like on the website. So this is the Next.js application. And this is a non-enriched PLP or category page. And as you can see, this looks rather plain. And in comparison, if we check the tops category, this is now enriched. And you can see there’s a banner at the top. You have some text here. And also for this one and the content fragment, you can select some products which are highlighted. And if, for example, if we go to one of the highlighted products, you can also see that this product was enriched. You also have like a banner, you have the stylist comment. And if you compare this now to let’s say again, a regular product that was not enriched, you can see how the concept of product enrichment and associated content can really improve your shopping experience. All right, so this concludes my part. And I hand over to James. Okay, thanks, Mark. Let me share my screen. Okay, well, so far, we’ve seen how we can use the API mesh to pull data from a commerce backend and use them to render storefront content. Now, we can use it to enrich that content using data from the app. What about pushing data to the API mesh? For this next section, I’m going to demonstrate how you can add a micro-findend that uses that same API mesh to add a shopping cart feature to this Next.js project. But first, what is a micro-findend? Let’s take a step back and define what a micro-findend is at a high level. You can think of a micro-frontend as a microservice in your application’s UI. Individually, these pieces would communicate with different backend services. But using the API mesh that we talked about, it’s possible to make these calls go to the same place. With the micro-findend approach, instead of a single monolithic front-end UI like you see there on the left, you have smaller modular pieces of the front-end which provide specific features, as you can see on the right. In general, these micro-friendend modules are usually external to the host application. They have their own independent build and deploy processes. And so when the application loads, it would load these modules from an external source and render them on the page. The API mesh, as shown here, can provide a central source of data for these modules, which they then use to provide features for the host application. For this project, we’ve added a shopping cart micro-findend example to the Next.js application. And this module is loaded from an external source, as we’ll see later on when we dig into the code. One of the main things this micro-friendend does is render a shopping cart panel with data from GraphQL source. We set the source to be the same API mesh that we use in the host application. And so it’s able to share the same commerce backend and data source. What this lets us do is add a product that’s rendered in the host application to the user’s cart and then have that change reflected in the panel and in the commerce backend. So how does this interaction work? As you can see in the slide, the shopping cart micro-friendend provides an API that the application can use to interact with the cart. And one of those is an add products to cart function, which as its name implies, lets you add the product to the cart from the host application. We set this function as a callback so that when the user clicks the add to cart button there, then it executes and sends a GraphQL mutation to the API mesh. And then it updates the cart in the backend and the cart UI on the frontend. Another piece of data that this micro-friendend provides is the cart quantity, which you can see there on the top right of the page. The cart micro-friendend exposes this as an observable value. What this means is that the host application can watch this value for any changes. And when the cart does publish and update, the application can update its UI accordingly. Now, switching over to demo, here we have our Next.js application. The first thing to do is go into the product and this particular micro-friendend requires an authenticated user. And so we’ll first sign in here. And as you can see, it shows how much we have in the cart. We had previously added some. We can open this up and you can see previous additions that I’ve made. We’ll make a selection here, add this particular item to the cart, and you’ll see it change up there on the cart counter. And then you’ll see it in our cart. And this is an actual functioning cart. You can add quantity. It’ll update the total by pushing data to the backend and getting the updated cart data. So let’s take a look at the code and see how we’ve integrated this microphone. One thing you’ll notice in the project itself is you won’t find the storefront cart code inside it. What we’ve done is we use Webpack 5’s module federation feature to treat this external module as you would a local dependency. So what that means is you can do sort of like an import in your code, like you would any component that you’ve says dependency. This import TSR only is a wrapper function we provided because we only care about client-side rendering. So you can see the storefront, the cart micro front end provides a render function and then the panels itself that we can refer to here in the component. And here we see the actual page where we have a customer token that we use to authenticate and then the add products to cart function that I talked about earlier and that we import from the API. And then here’s where we set that call back on the add cart button where we add the products to the cart. And that’s it. That’s how we’ve integrated the cart micro front end to add this commerce feature to our Next.js project that’s attached to the API mesh that we talked about. And with that, I’ll hand it over to Marcus to close this out. Thank you James. And let me now summarize the session. We have a few action items prepared for you as a takeaway from this session. Let me start with the first part. As you have seen with the API mesh, we have a tool and solution for building your project specific individual back end for front end for your headless AEM and commerce application. With the tool, you can stitch together AEM content fragment graph graph APIs, Adobe commerce APIs, and your project individual APIs as well. You can modify and tweak the schema as needed. You can adjust and rename portions of the schema, filter parts you don’t want to make visible to your end users, etc. And once your API is ready, your front end developers can start using it. With that, we are the second part of the presentation. As seen by Mark, we have a project template or you can start by scratch to build your content and commerce headless application. You can use the enrichment tools we have in CAF to add commerce relevant information to content fragments and use them together in your front end to build appealing experience to from commerce applications and websites for your end customers. Once you’re happy with the result, you already can go live because you can show off your products and you have your entire product catalog, including the content fragment enhancements ready for your end users. As a next step in the third part, we showed you how you can use our microphone vents to add commerce transactions and make the entire experience shoppable. Adding a shopping card to your site, no problem. Adding events for Add to Cart and other commerce related actions is also possible with the micro front end approach. And we encourage you to go to these two steps, play with the sample application which is available on GitHub for your project starting as a blueprint. And with that, I’d like to say thank you. We are happy to continue the conversation on Experience Leak. Also try out EEM headless and App Builder headless trials. A few references as mentioned in the talk to all the topics we showed and explained to you. And with that, thank you very much.