What APIs and Services do you use to make a great Commerce site?
We get this question a lot. I understand why. The concept of stringing API-services together to make new and innovative solutions is not necessarily one that is easy to grasp. Here are some pointers to how we do it.
Like with most kitchens and chefs, there is not ONE recipe that will work for every party. Instead, there is some of that, a little bit of this, and a pinch of whatever else. When we build new customer-solutions, we go into the API Economy to forage. Here we find APIs and services for most everything. In addition, we build some services ourselves – and throw those into the mix too. It could look something like the image below, where a dot in the matrix represents a separate API-service (the only reason we have inflated our own service in the matrix is that we want to illustrate that it too consists of a range of micro-services).
In this example, we pull services from three API-based 3rd party services: Blitline, CKEditor and Algolia (services for image handling, text editing and search respectively) into a customized instance of our SaaS-solution. These are just examples and there are always many more services in use (but we display only three here to keep it simple). We then add some of our own services, such as our PIM Grid, and other secret ingredients. All of these are generally exposed with their own management functions in the SaaS-service back end (the manager interface) – and they are sometimes exposed as functions in the front end (here represented with page-icon www…). Other services may not even have a front-end view related to it.
The Algolia search for example, is a separate SaaS-service running in the cloud. It can be controlled via a manager interface in our back-end service and - last but not least - as a search box in the front-end (web-page). The same goes for CKEditor, which may be used in our back-end to edit text that is visible in custom front-end templates (but has no front-end except for the configured text itself).
Because we use API-calls to these services and generic functions in each one separately it is fairly easy to swap one service for another. Say, for example that you for some reason don’t want to use Blitline for image handling, but instead think that Cloudinary is the bees-knees, well then you call those functions from Cloudinary’s API instead. The performance in one of the API-services does not affect the others and it is therefore possible to do the swap more or less "in-flight". This is what we have called the Always in Beta approach to development.
Now, this was a small taste of our secret sauce. Its time to make your own!
Want to get a more in-depth explanation to using API-services to build a commerce site – or other commerce applications for that matter? Keep reading or get in touch!