Create a mesh with multiple sources

Transcript

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 out of the box with Adobe 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. The next example would be product selectable swatches or other complex attribute types. Well, this complex attributes 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.

To update the mesh with the new config, we’d simply have to run the update command. IO API Mesh Update and provide the configuration file. Note, if you don’t provide the configuration file, you will just use the last configuration file that we used. This will try to log me in if we haven’t used API Mesh for a while. Now that I logged in, I can click yes. Be sure to check if this is the API Mesh that you want to update. In this case, we only have one of them. You can also specify the API Mesh ID that you want to update. This will use the last configuration that existed. In case you get an error like this, it must be the fact that you have an error in your configuration file. Let’s go by editing it and repeating this operation. In this case, it is complaining about the name. There is no spaces allowed in the name of the source. To remove those spaces, proceed and do it again.

Sure enough, this worked. We can check its status. And we can see that the source of the schema actually generated an error or it couldn’t actually join the two schemas because of an error of stitching. In this case, you have to fix your source in order to do the proper stitching and retry this operation again.

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.

I went ahead and fixed the errors that I had with my GraphQL schema so they don’t conflict with my existing schema. I can now go ahead and repeat this operation. Hopefully, it will go successful. I can try the update command again.

And I can try status. The API Mesh status ensures me that everything completed correctly and I can proceed to access my unified schema. One last item in my workflow is to save my changes to Git. I can add my changes to the JSON.

I can actually commit them.

And check my log. I see that I actually have two changes. This completes the workflow that I wanted to showcase.

If we are to look what does this mean to the schema GraphQL level, we will see that attributes metadata was defined in the query level and this is exposed also that under product interface, we expose custom attributes, which is also used at the query level. When combining schemas together, we can see that it joined one source of the schema by deprecating the custom attributes metadata, which was included in the first scheme. One source affected the other. This will introduce custom attributes as part of the product. You will also have to deprecate all the other custom attributes that were present in the Venya source so they won’t conflict with the new way in how new attributes are consumed. This concludes how API Mesh stitches schema together from different sources in a single endpoint.