API-First micro-frontend applications
API-First micro-frontend applications
Because I expect this content to be consumed by folks that are new to web development, as much as seniors, let’s start by defining an API. API stands for Application Programming Interface, and it is not just code: an API is a collection of definitions, specifications and protocols that enable the communication between two parties or entities.
On one end the client -the entity making a request for data-, and on the other end, a server, or the entity responding with the data.
APIs are written with different principles in mind, and they can be designed using different models and approaches. There are several types like RESTful, GraphQL, gRPC, tRCP, etc, and much older patterns like SOAP. I will just briefly describe the two first, for now, and will extend with information on other patterns, as I continue to develop this site.
APIs as the core of the system
When designing an API-First system, APIs are the central part of it and that’s why it requires a complete mindshift from the monolithic patterns we’ve been developing with, for the past two decades, or more.
An API-First approach enables system designers to think about the frontend as a dettachable component of the system, sort of like a plug-and-play user interface.
With this approach, the application processing or business logic and transactions become dettachable, too. In essence, an API-First approach makes it easier to adopt a service, particularly a SaaS -Software as a service-, to adopt micro-* patterns -be it micro services or decoupled frontends- and to design a migration in or out of a legacy implementation.
Separating the API from the business logic
In a monolith, the API is tightly coupled with the business logic, and the UI events. This means that the API is not only responsible for exposing the data, but also for processing it, and for handling the UI events.