API vs Microservices — Are you using 2 terms for the same concept?
No, you’re not, but let me explain
Microservices and APIs are two terms that we hear quite a lot in our careers. Especially so if you’re working on web development. Who hasn’t interacted or even created a REST API on their project? I bet you can throw a rock into a room filled with developers, and you’d hit someone who can tell you about their experiences with APIs.
And the same goes for microservices, to the point in fact, that these two terms start getting used interchangeably. But are they? Or have you been using them wrong your entire career?
Let’s see.
What is an API?
API stands for Application Programming Interface and that alone should tell us exactly what it is. But because we can’t really end the article here and leave everyone more confused than they already are, let’s try to deconstruct that definition.
APIs are your gateways into the realm of remote logic. Or put another way, they act as a way for you to communicate with a piece of logic that is not locally available to your code. Hence the word “interface” in their name.
They are a contract between two parties:
- Your code, on one side, which needs the functionalities of a remote service.
- The remote logic, on the other, which has a set of functions available, but is unable to use them for itself.
You can think about your code as the clients in a restaurant, all they want is to get the food and eat it, they don’t care about making it.
While inside the kitchen, you have the chef and everyone else working on getting the food ready. By themselves they make no sense, their services need to be used by others (the clients).
But you’ll never, as a client, go into the kitchen to directly request the food you want, wait for it and then take it to your table, will you?
That’s where APIs come into play, they allow you to interact with that remote service (the cooks) by simplifying that task and abstracting you from the intricacies of that hidden logic.
And on top of that, the concept of “contract” adds the fact that this interface is — or at least attempts to be — standard. Through this contract you’ll specify things that will work exactly the same for everyone using it (every client will request the food the same way):
- The channel of communication.
- The list of features available and the way they can be invoked.
- The input and output data formats.
- Error conditions and messages.
- Response codes and their meaning.
And we can probably keep going. The point here is that anyone using the same API will get the same treatment. They are meant to simplify by abstracting.
As a client of an API you don’t really care what’s behind the curtain, you just need to know what the API tells you and that’s it.
There are many types of APIs, while we might associate the term to GraphQL or REST, there are others that while older, might still be relevant for you:
- RPC or Remote Procedure Call. This one allows you to execute a piece of code (a method or a function) that is somewhere else, as if it was local to you. I wrote an article on how to create such an API using Node.js here, check it out.
- SOAP. No, not the kind you use to clean yourself, in this case SOAP stands for Simple Object Access Protocol and it allows you to execute remote functionalities in a very generic way using XML to transport information from one place to the other.
This is why they’re such a common technology at this point, where every piece of technology we use needs to generate some kind of data and transmit it somewhere else. Through APIs we’re able to simplify and reduce the amount of work required to connect 2 (or more) systems.
What is a Microservice then?
Here is where the line gets a little bit blurry at times. You see, microservices are essentially pieces of logic independently deployed and ready to be used by other systems.
Usually users don’t directly interact with them, instead, they use other systems that use these microservices as external resources.
The “micro” part comes from the fact that they’re meant to be considerably smaller and self-contained than their parents (monolithic services) were. They make a big deal of the Single Responsibility Principle, making sure that whatever set of functions they provide, they’re all related to the same topic.
Think about a big system that needs to interact with a database quite a lot because it keeps a lot of business entities saved there. Things like users, invoices, delivery routes and so on are all stored in a database.
You could have your code directly using the database from anywhere inside your logic, or you could, potentially, have a microservice dedicated to data management (storage, retrieval, etc). That way such a big responsibility could be self-contained, scalable, easier to maintain and easier to change if required.
That is the top 1 benefit of microservices, they can be used as lego bricks if they’re built correctly. You can then re-used them, modify them individually without affecting the rest of your system, they’re fantastic.
The only issue with them, is that by definition, they don’t have a standard way of using them. Granted, in practice we all know how to do it, but let’s not get ahead of ourselves.
By definition we can use microservices however we see fit, and while you might jump right into thinking that an API is needed here, let me tell you: you’d be right.
Are they the same thing then?
It’s hard to bury the lead anymore, so I’ll just go ahead and say it: the microservice is nothing without the API. Just like the API has no point without a microservice behind it.
Consider the following example architecture:
By the looks of it, we can’t really tell much. All we know is that there are some microservices dedicated to different topics, such as log-in, handling orders, invoices, users and a generic one for data management. That seems very standard, right?
Well, if you put on your special goggles, this is what you’ll see:
Every microservice has its own API contract, defined and being used by other services.
So no, APIs and Microservices aren’t the same, but they do work together to form a single entity. By themselves they can be used, but they would make little sense or they would just not have the ability to be used by others. This is one of those cases where Aristotle got it right, the whole (as in APIs and Microservices together) are greater than the sum of all parts.
Build composable web applications
Don’t build web monoliths. Use Bit to create and compose decoupled software components — in your favorite frameworks like React or Node. Build scalable frontends and backends with a powerful and enjoyable dev experience.
Bring your team to Bit Cloud to host and collaborate on components together, and greatly speed up, scale, and standardize development as a team. Start with composable frontends like a Design System or Micro Frontends, or explore the composable backend. Give it a try →
