Loading Form...
Oct 13, 2021 | 9 minute read
If you’re in the eCommerce space, you’ve likely heard of “APIs” and “Microservices” at least once. Conversations surrounding these terms often circulate when trying to compare eCommerce solutions for practitioners, and when trying to execute tasks for developers.
“Oh well I heard that eCommerce solution has 300 Microservices”
“I want my solution to be API-First”
“It’s easy to do this with a few API calls, it should only take a few minutes”
Because APIs and Microservices work so closely together and often overlap in their uses, experts tend to speak about them freely without much context. However, this often leaves non-experts confused about what they really are, how they are used and how they can benefit their eCommerce solution. That’s why I took the liberty to talk to one of our experts here at Elastic Path, Chris Wraith, Director of Engineering, to provide some context on the basics of APIs and Microservices. Take a peek at our conversation below →
Shaneil:
Chris, I think it’s best to start at the beginning with “What is an API?”
Chris:
The root of APIs comes from Application Programming Interface which really just describes a contract between different parts of a program and a system. In the context of web and eCommerce, when people talk about APIs, what they mean is HTTP APIs, so for example, REST APIs or JSON APIs. But when you boil it down to its roots, it’s a contract between a service provider and a client where the service provider agrees to provide something given a certain input.
To break it down even simpler, what is an example of a service provider receiving an input?
If we look at an eCommerce example, an example would be if you had an inventory service. An inventory service might have an API called “get inventory”, it takes input of a product, and maybe you will get back something that tells you how many of that product you have. So effectively it's a contract that says, “if you give me this input, I will give you this output and here's how you get that information and here's what I need to provide you that service.”
So, APIs are a lot simpler than I thought because they can be used a lot in everyday life.
Exactly! The thing with APIs -- They always have an objective and they always accomplish something. Sometimes it's a simple matter of, if you give me this input and you get this output or sometimes it's you request me to do something, then I'll go off and do that.
It could even be as simple as a request to calculate the sum of a list of numbers, or it could be more complicated as providing a text transcription when an audio file is inputted. But as you said, they can be used anywhere -- Anything you can encapsulate in a contract or any service you can describe can be an API.
So, it seems like APIs have been around for quite some time, so why is there now a huge debate about choosing between API-driven eCommerce solutions and out-of-the-box eCommerce solutions? Because I’m assuming APIs are still working in the backend of the out-of-the-box solution, but probably with just less availability to be customized. Can you help to clarify that?
Well, it depends. When people say that they want APIs in a commerce solution, what they really mean is that they want APIs to be first class citizens. They want the APIs to be the things that they're paying the money for when they buy that particular solution.
However, when you buy an out-of-the-box solution, what you’re most likely to get is a set of templates where the APIs are underneath it all. So, you don't necessarily get access to the APIs, but they are probably still there. In an out-of-the-box solution, providers might not want to share the details of these APIS because they might think of the APIs as only being for them and not for the customer.
Whereas when API is the thing that the customer is buying, they get to consume those APIs in whatever way they want, across all of the customer journey. This grants the ability to construct that really custom and perfect user journey that you want for your customers and that's the, you know, the uniqueness that you get with Headless Commerce.
Shaneil
That makes so much sense. The flexibility granted here is key. Is there anything that clients really care about when evaluating APIs with an eCommerce vendor?
Like I mentioned before, the important thing about an API is that it's a contract. So, from the client's point of view, they know that if they provide the particular input to the API they'll get a particular output. And that’s all they really care about. They don't really care how that operation is accomplished; they just want to get back the right output.
However, one more thing they might think about is how long it takes to fulfill their request. Part of that contract in a lot of cases is what we loosely call the “non-functional requirements,” i.e. how long it would take to process or the performance expectations around it. But generally speaking, clients might care about the inputs, outputs, how long it's going to take and how it performs.
Is there a way that a client would be able to know right off the bat if eCommerce vendor’s APIs are slow or not?
Well, most service providers will give an idea of how long the requests in their systems are expected to take. At Elastic Path we try to ensure that all of our requests return within a certain time (100 milliseconds). But generally speaking, it's not always something that people publish with their APIs. However, an important consideration when you're buying a solution is whether the API requests will be fast enough for your needs.
Thanks Chris. So, let’s shift over to microservices. In your eyes, what are microservices?
Well, for me, it's the way of architecting an application. But as you know, there will be a lot of disagreements about what the exact definition is. So, what I like to do with these things is to take them back to first principles and understand why they were designed that way. And for me, microservices is really just about implementing an age-old idea in computing, which dates back to the 60s and 70s, which is just always making sure that things that you build are loosely coupled and highly cohesive.
What that means is that where you have different parts of the system working together, when they talk to each other via APIs, which we’ve just spoken about -- those APIs are well defined contracts which creates this sort of loose coupling effect, where changing a something internally in the system in “A” doesn’t affect the system in “B”
And so microservices are really just a design principle that helps with loose coupling and high cohesion. This means that you can have all the related functionality together in a single micro service and still interact with functionality from another part of the system without being tightly woven together to break the function, but still cohesive enough to work in symbiosis.
So, how do microservices solutions differ from traditional monolithic solutions?
You know, people bash monoliths all the time, but Monoliths can be well designed as well. It just all comes back to that old software engineering principle of loose coupling and high cohesion. So, this can definitely be achieved in a monolith as well. However, the reason we use microservices is because we think it's easier to achieve that loose coupling and high cohesion. Working with microservices kind of forces you down the right route and makes it much harder for you to make bad design decisions if you're in a well-designed microservices environment.
When you compare that to doing it in a monolithic set up, it's really easy if you're a developer in a monolithic application to make a decision and add certain functionality in a section it wasn’t designed to be in because it also holds similar functionality that you recognize. So, when a developer adds their code in the wrong section, you end up losing that cohesion and introduce tight coupling between components that really shouldn’t be coupled together. And that is when you get that scenario where somebody makes a change in “A” and breaks something else in “B”
Oh yes, we have heard so much about companies struggling with these issues in the backend of their system and therefore have had to implement continuous regression and quality assurance testing to avoid any breaking. So now that we have a basic understanding of both terms, what would you say is the main difference between APIs and Microservices?
So, an API is like your contract, and it says this is what this particular thing does and the microservices, how you would implement that contract. I will say however that it's not necessarily a 1 to 1 mapping between them. So, you might have an API that has a number of different capabilities in it, and you might have one micro service that implements all of them. Equally you might have another API that sits across two or three different microservices that all come together to implement that particular piece of functionality. So, in all, the difference is that an API is a contract that says “given this input, you'll get this output,” while microservices is a way of delivering some or all of that functionality.
So essentially microservices work in conjunction with APIs to fulfill clients’ requests. So, do you have any final advice for customers regarding microservices and APIs?
Well, if someone is thinking about the way that they should design an eCommerce platform, they will probably want to be thinking about microservices for themselves, but when it comes to choosing an eCommerce provider, they want to be thinking about APIs So my point is, for the bit of the solution that they want to build, it makes sense to build them as microservices because then you get your nice loose coupling high cohesion, that we all aspire. But what you really care about when you're getting services from other people is APIs, because you want to know what you’re getting, what you need to give that service to get what you need from it. Thinking about that means that, you know, the bits that you design are well-designed, and you know exactly what you're going to get from all of the providers that are going to come together to form your eCommerce solution.
Well, I hope this was helpful in understanding the difference between APIs and Microservices. You can explore more about microservices and understand if they may be right for you here. But as always if you have any questions feel free to reach out to us over chat.