Create a mesh with a single source

Transcript

In this video, we will use a sample JSON provided with our documentation which will proxy Adobe Commerce sample store called Venya. This tool will provide a GraphQL endpoint with a live API through Adobe Mesh. In a JSON config, you can specify multiple sources as an array. Each source is an object, each source has a name, and a handler can contain multiple things. In this case, we’re using an API source as a handler by specifying a URL as an endpoint. This must be a working GraphQL endpoint with a valid schema. To check if your endpoint has a valid schema, we can do the following. We can go to the store, we can click on the inspect, and this goes for any GraphQL enabled website. We can go to network and we can start browsing. Ideally, we will filter here by GraphQL. This will generate some traffic and by clicking in the first captured URL, we can see here that all traffic is going to this URL, which is the source that has been given here. Furthermore, we can make sure that the GraphQL query works. We can use a GraphQL extension or anything that browse a GraphQL schema. Here, we can see that the schema was actually loaded correctly and we can actually explore it. And we can also try to make a query. Sure enough, this ensures that the GraphQL works correctly and it is safe to use it when creating an API mesh.

Next, we can copy this sample JSON from here and paste it into a JSON config file, which will be part of our project file. We’ll go into the console. We can either use Vim or nano, paste this JSON, save it. And after that, we can check its creation. Next, we are going to run this command, IO API mesh create and provide file name, similar to what is described here in the documentation. I’ll prompt it, yes, I want to create a mesh. I will double check here that if I am into the selected organization project and workspace, remember one API mesh endpoint per workspace. In this case, I am creating it on stage.

After running this, I’ll get a prompt with a few takeaways. This is the API key that was provided to me also in UI. This API key is actually public because it will appear as an endpoint and a public URL, just like so, and the actual API mesh ID that will be used for this.

You will notice that the system is also giving me the full URL from which I can actually access this endpoint. Do not attempt to access the endpoint right away as this is an asynchronous process and it will not be available in the next second after it’s being created. To check the execution status of API mesh, we can run the following command as specified here.

In this case, it is prompting me that my API mesh has been successfully built. In case you have large source files or slow endpoints, this process can take more time than this. We can actually copy the URL from here and use GraphQL or any browser that will let you navigate GraphQL. We can paste here the new URL. It will load the new schema so we can see that actually it provides quite the same schema as venya.magento.com, which means that it is actually processing through API mesh. Furthermore, we can run the same query that we tested before and we can see it is providing quite the same amount of information except it adds something like extensions at the end. This will tell you that the API mesh endpoint runs correctly.

Next, let’s try to stitch two sources together. Imagine the following scenario. You have to render a set of attributes in a list with a label plus a value. All of that is provided by the box with the W e-commerce. But what if you need to render a more complex UI? You will need to access a complex attribute schema, which will enable it to render that complex UI. A good example would be product selectable swatches or other complex attribute types. Well, this complex attribute schema exists in a different source as an add-on or customization. You have to make available your customization in your PWA and consume this complex attribute data as a single schema or graph and let API mesh deal with the composition of multiple backends.

Let’s have a look at the schema which we’re trying to compose. I’m referring here to custom attribute metadata, which is the out of the box schema in Adobe Commerce. This schema provides a more simplistic approach to attributes. Next, we’ll have a different source which provides a schema for more complex attributes provided by this query. This query will also have to deprecate the old schema like so. All of this is provided in a different source. We’ll have to combine these sources together in a single graph using API mesh. The result of that will also be that while trying to consume the more simplistic attributes like they will also have to be deprecated as part of the product. When combining these attributes, the result will look like this. This will introduce a custom attribute as part of the product. You will also have to deprecate all the other custom attributes that were more simplistic in the out of the box Adobe Commerce. When combining schemas together, we can see that it joined one source of the schema by deprecating the custom attribute metadata which was included in the first schema. One source affected the other. If we have to look what does this mean to the schema graphical level, we will see that attributes metadata was defined in the query level and this is exposed here also at the top level. Also that under product interface, we expose custom attributes which is also used at the query level. This also gets stitched together here in the final schema in the product interface. We also notice that all the other attributes are gone and deprecated at the end. This concludes how API mesh stitches schema together from different sources in a single endpoint.