Innovating with Headless Integrations - A Closer Look

Transcript

At this point, I’m going to introduce Christian Partica. He’s going to talk a lot about really how this all comes together. Again, with the past, current, and future with a focus on APIs, GraphQL, etc. I’m excited about this one. Again, just want to introduce Christian Partica, our Senior Product Manager for our extensions and our API strategy. I’m Christian Partica. I am a Product Manager for integrations at Adobe Commerce, and I’m excited to share with you today how we can innovate with headless integrations. A little bit of background about me for those that did not have the pleasure to meet me before. I was a developer for a bunch of years working on the GraphQL API layer. I’m deeply knowledgeable about how this actually works and about the business of headless integrations in general. I’m happy to conduct this presentation for you today. Let’s see what we will learn in this presentation. I composed a mix of the why and the how, and we’ll also take a sneak and peek behind the curtains to see how we’re conducting this internal development. We’re looking at why is headless developer architecture so appealing, and why headless commerce? As developers, it’s important to know why we’re doing this. It is also more apparent for me as a Product Manager or for a business, but it’s also very appealing for a developer, and I’m going to explain to you exactly why. I’m also going to talk at this stage about innovation beyond the buzzword. Next, we’re going to talk about API usage and workflows and how application use the API, and this is very important, best guidelines and practices and workflows, and how they affect our consumers. Next, enhanced performance and scalability for APIs. We have some big announcements to make in this space, and I think our teams have struggled to actually go beyond what we ever hope for, and I’m happy to share some numbers with you for the upcoming 4.4 release. Backwards compatibility and handling schema changes for your integration, that’s another topic that I want to go to. Making your APIs extensible in the new API platform that we’re rolling out in a deep dive to see how it will work and close to look at its diagram. This sneak peek about guidelines and back practices and API design and how we’re thinking about our schema, and a little bit of knowledge about our internal organization, about our schema council and API, as all our products will actually integrate and also integrate with third-party and different experiences. Let’s go with the first point, why headless? To me, this is a good question to start with. As you know, headless architecture is decoupling the front-end from the back-end and connecting them through an API. But headless is beneficial for developers as well. Well, what’s in it for me as a developer? Well, for once developer can focus on what matters. There’s no need for cross-pollination. You are free to choose your stack of choice. If you are a back-end developer, you can keep using Java, PHP, C-sharp. All those years of knowing the Magenta framework actually do pay off. You can keep your career focused and become an expert without having to learn other languages like JavaScript. If you are in JavaScript, you can keep innovating in that space. Employers will also hire you for expertise in your stack, not for your broad full-stack knowledge. When developers specialize in one stack, they become so good that only at this point, it actually drives to innovation. You keep hearing about the 10,000 hours that you need to become an expert at. I think content and commerce needs this innovation today, and needs this expertise to align and drive innovation and compete in this very outstanding markets that want this innovation today. At the basic level beyond the bias board, true innovation starts with the people and the technology. So developers are the center of it. They make this technology feasible, making the business viable, and to be desirable by our merchants and our customers. Headless allows parallel software development lifecycle, as long as the two systems, the back-end and the front-end, agree on one API contract. This allows you to spin up multiple front-ends, multiple experiences, and focus on customizability of these capabilities. This wasn’t really possible before in a full-stack environment. So one back-end, multiple front-ends, I won’t add even more back-ends that add up to a single layer, and then spinning up multiple front-ends, it adds the center of the headless. Going to look at API usage, best practices, and workflows. Adobe Commerce uses GraphQL for its storefront APIs. We do this to enable Adobe Commerce to have a headless architecture. And yes, we do support it today. For convenience, we also provide out-of-the-box integration with our PWA studio. As a developer, you can choose which area you’re interested in. If you are a back-end developer, one of the reasons for why you would use GraphQL is basically to drive API usage specialized for data fetching. This means that it can sometimes be hard to understand how to compose the right query in the right way for your PWA usage. The way you compose the queries and the data you use can directly impact the experience of your end user. The back-end has to account for all of that. So it is important when you customize your API to take that into account. Take the mini-card, for example, which I highlight here on the left. You only need to do a very simple query to render it. But it has to be rendered on every page. The data needed for mini-card is different than the data for the full card, which is subsequent predictable next step in the workflow. However, this full card doesn’t have to be rendered on every page. The true power of PWA is that it’s progressive. That means that we can anticipate the next move of the buyer. We can fetch the data needed for next steps as they’re predictable in this workflow. And we can have ready-to-go data and render the next object that the buyer has to interact with. And all of this happens in the background. Service workers have allowed PWA to do this in ways it was not possible before. So browser support has enhanced this possibility. It can also be deployed in different devices. So chances are that the user will click on the mini-card after one to second scanning the page. And the next thing he’ll going to do is see the full card. It is all about predictable workflows. And that’s how we think of our API. And we are addressing speed and interaction this way. GraphQL is the perfect technology to do this as opposed to REST because you can select the data you’re querying for. So to go further in this workflow, the next step in our cart is the checkout. And I included here such an example of a query that you need to actually include to render it. And it can happen in the same fashion. Looking at API workflows, they’re not always linear. Depending on the store admin configuration, the workflow for this user experience might change. And your PWA has to support all these conditional workflows. And they’re driven by the API itself. When designing the API, it is important to understand this concept and empathize with the consumer, which integrates with your API. In this case, it’s PWA. If the PWA is constructed in such a way to just adapt to the workflow as is driven by it in a dynamic way, there will be no need for hard coding on the front end of how these workflows actually will work. It’s the API that drives the workflow, not really the front end. The front end just shows the experience. That is why we like to think that capabilities can be expressed through APIs and experiences through PWAs. Take this out-of-stock situation, for example. Shopper behavior in commerce has completely changed since 2020. With increasing demands for certain products and low stock availability from warehouses, we see websites having to adapt to this new change and edge cases. And some edge cases, like out-of-stock, not really edge cases anymore. But they can become blocking for the shopper to interact with. We improve our out-of-stock workflow and enable PWA Studio to better render these events. The experience has improved by simply giving proper information about the situation that the shopper is in and also give more information about the low stock availability without giving up too much information about the actual stock that the storefront has. This approach better fulfills the unique purpose of an e-commerce store, to make a sale while having returning customers to a store by giving them a proper experience. A goal for our back-end engineers has always been, for every release, to add performance improvements to our API, despite of our caching efforts. In turn, this enhancing of an experience of the front-end is to make our product more desirable and to be a pleasure to work with. The graph shown here is a snapshot of our API performance trend. We measure almost every interaction that the buyer or the admin is doing with Adobe Commerce. We have data that’s tracing back years ago, and we’re measuring this daily. As you can probably see, we have dramatically improved some measures in this space, by as much as 80%. This is stellar work from our internal developers, and true innovation as performance improvements is a hard problem to solve when you’re keeping the same stack. Note that these measures count as the first page load. They’re not cached in any way by any edge caching, though we have improved on that as well. Considering we actually looked at the usual PW web traffic, and we can probably say that we’re actually providing edge caching for about 80% to 90% of it, depending on the app itself or the quality of the traffic. This means that we can actually respond with as fast as 20 milliseconds and account for 80% to 90% of the traffic with that speed. Commerce application performance and scalability is a critical part of every Adobe Commerce release. We have made a number of improvements over the last few quarters and released a performance white paper, which contains benchmarks, contains performance comparison between the 2.3x release and the 2.4x counterpart. Some highlights from this benchmark include 20x improvements for product SKUs effective support. We went from 10 million to 200 million effective SKUs. That’s a huge improvement, all in the same stack. Up to 3,000% improvement in our ability to process order within a given hour, we went from 1.7k to 60k, 60,000 orders per hour, with just a minor solution that our engineers have thought of. One of the biggest highlights in the support of this orders per hour, that’s actually our asynchronous order placement. This is exclusive to Adobe Commerce merchants, but it’s especially useful for merchants that are on the B2B space or experiences flash sales or want to be ready for holiday sales. Handle schema changes and backward compatibility. Compatibility and continuous schema evolution and deprecation is built into GraphQL. We always thought this and took this very seriously because we have multiple consumers that are the Pentagon schema, and we’re very intentional about backers compatibility. The API evolves continuously in order to better support workflows, and this is the only way to actually progress and innovate. As a consequence, all releases will contain new fields, objects, and an improved schema experience. When these changes are needed, where we first deprecate the old fields or entire workflows for that matter, but we only remove them in other releases, not in the same release. As an integrator, depending on the schema and on this API, you should know that all deprecated fields remain functional until their removal. This is a good practice is to check your installation for usage of fields that are deprecated or about to be removed before you upgrade. So we provide such a tool, and it’s an upgrade compatibility tool, which I suggest you to use and cross-check your schema before you upgrade so you can prevent this from happening and actually account for your tech debt. However, this tech debt is much more minimal for just the API rather than modifying your whole code. As mentioned, Adobe Commerce is known for its extensibility, high customizability, and a network of professionals and extensions it provides. Developers that work for Adobe Commerce are very familiar and know how to customize this platform. For the GraphQL, the main engine for customizability is schema stitching. This is true in our current platform, and it will continue to be so for our new extensibility platform that we’re building. We will continue to have API stitching in the legacy platform, but now you will be able to mix different services which are deployed separately, including the core. These services can look like live search, product recommendations, or even AEM, SIF. One more powerful benefit that I will add to this is that you can bring your own API. You can stitch together in a single API, which your APWA interacts with, without the needs of cores. And you can add existing APIs, let’s say from Google or other vendors, but also create your own. Across 2022, we’re continuing to evolve our platform and maintain its flexibility while accelerating the features that allow innovation and reducing overall total cost and ownership. This is the goal for this platform. This Decouple API platform will allow developers to extend and customize capabilities through Adobe IO and App Builder, with serverless functions. This will allow you to serve different stores in a headless fashion, in a true headless fashion. These stores can be PWA, mobile apps, smartwatches, personal assistants, or even VRs. We’re constantly striving to define and evolve our API and extract the best practices, but also how to articulate them. In part, we’re keeping up with the GraphQL spec, so our schema, it is compatible with our GraphQL spec as much as possible, which gives the familiarity to a developer starting with this API. However, e-commerce use cases might be different from CMS or other use cases, right? I would like to acknowledge our vibrant community, which helped us get to this stage. We could not get to this stage without feedback from our committee of professionals, partners, and other independent agencies, which we’re collaborating with. We also drive inspirations from industry leaders, right? A lot of our industry leader platforms already have APIs. And I would like to point out something that I do see one day that we will have a common guideline for commerce API based on the most common e-commerce workflows. Our goal is to offer the best in-class industry standard APIs, which our developers can feel good about consuming them. If there was ever a price for the best API, we would like to be on that podium. I do want to encourage partners and agencies to think structurally about headless strategies and experience frictionless headless integrations. This is a new technology and it is becoming at the center of attention to how agencies customize their systems. And following guidelines and best practices is a must when beginning such a journey. So this is not trivial task. In conclusion, what we could articulate about how we compose our schema is that they are intentional, declarative, familiar, extensible, but most importantly usable. And lastly, at Adobe Commerce, we do have a dedicated schema council, which this is the sneak and peak that I was talking about when I started the presentation, which addresses concerns X explained in the previous slides. It is important for different products to work together through an API, which is at the center of the developer experience. The schema council is a working group with representatives for each product that we have in Adobe Commerce or exposes any API. Through this API and schemas teaching platform, which is the new system, all these products will come together and the efforts of this team actually become a little bit more apparent, right? So all these guidelines and making all this product work is very important. The goals of this team is to identify, imagine patterns and use cases for API, provide the best developer experience, offer the same look and feel for all content and commerce APIs. This is the familiarity part. Conduct R&D, gather feedback, formalize into best practices and guidelines or emerging workflows. And finally, educate, educate, educate. We are exposing our APIs in two ways. You can use the built-in defined GraphQL docs, but you can also go to our dev docs and you can follow the link here. You can also Google it. It will come very handy for you as a developer. And you can also contribute to these docs if you want to make them better. In conclusion, Headless allows complete separation of the backend from the UI. It allows predictable workflows to flourish and make UI interaction faster. Commerce APIs performance improve with every release and we are absolutely serious about backwards compatibility. Extensibility to streamline stitching will be done through a new platform. As we have a lot of expertise in our schema stitching from the legacy platform. Our schema design philosophy focuses on the consumer and has certain guidelines that you can take a look at. And lastly, we are on Slack. If you want to connect with the almost 2000 professionals, please scan this QR code and you can actually start talking to them today, contribute and it is there where you reach me and my teammates, which are very helpful and will help you in your next Headless journey. All right, with that, I am gonna turn it to questions. So we have one question, if I can elaborate on the new legacy platform. Yes, so as shown here, the new legacy platform will continue to exist as a service, right? So everything will actually be a service as we’re stitching multiple services to the legacy platform. The schema stitching concept actually remains the same, except you can do schema stitching at the legacy platform, which will join at the higher level with this new commerce API. So you can actually, what will exist at least for years to come? So the new legacy platform will continue to exist for years to come. Yeah, that’s a good question. Yeah, actually schema stitching was the technology of choice as opposed to federation that we chosen initially a few years back when we started with our legacy platform and offering GraphQL. We’re just expanding more customizability possibilities with this one. Yeah, and the way we’re looking at this relative to release is this is still the core platform, right? So as we look at the different variations here, it’s really important to make sure that we retain the compatibility between all these different layers. It’s something I know that Alaina and team really take to heart with the work on PWA as we do with everything else. And so as we look at some of the exciting pieces around STS, LTS, et cetera, we’ll wanna do the same thing. So I think that’s why the council and making sure that we do have a lot of these conversations that these interlocks in place, we’ll make sure that it’s all compatible in any form that we’re looking at. So I have another question about the points that I was making about the guidelines. So what does it mean intentional and declarative? So intentional means that you will do specialized APIs for your consumers. You have multiple consumers. If you think about PWA Web Store, that’s a consumer. So you have to be intentional with those workflows. And you also have to be intentional with other workflows like CIF or a smartwatch or a personal assistant. So specialized API that directly addresses those needs, that’s the intentional part. Do not make a all-in-one query that cannot be necessarily used by everybody and try to fit everything in one. And declarative means that you can read your API, you can understand it, and it drives the whole workflow from A to Z. Good objects, readable objects, good typing, will actually allow a very good declarative schema to be usable by the consumers. All right, I think we’re good. Hey, Christian, thank you so much for all of your work in this area, both again in what you’ve done and how you’re doing with the community. I can’t be more thankful for how this is all coming together. I think everybody is really starting to understand how that is and where their part is in any event. And of course, you’re always accessible and can be reached for any questions along the way. So thank you again. We’ll take a quick break and we’ll be back here shortly.