What is the Micro API Design Model?


Software development has evolved rapidly in just a decade. From deployment to physical servers, to virtualization and IaaS to PaaS. A hot trend is FaaS ( Function-as-a-service), such as AWS Lambda, where you deploy snippets to run on command anywhere in the world. The latest development, however, is the Micro API, who Built on Serverless Computing and FaaS to take API development to the next level. Lukas Rosenstock on the CloudObjects blog introduces the concept.

Lukas defines a micro API as a design model for software that meets the following criteria. It exhibits a Web API (eg REST) ​​to a client in a single file with only a few lines of code. This file is based on a Framework and a set of dependencies and has no local state.

Anything that matches these criteria can be executed in an execution engine that provides the appropriate framework and dependencies. The small amount of code then means that it can be deployed on demand. A request arrives, the code is retrieved from a Repo, cached in the engine and executed. A runtime can be multi-tenant, which means it can run many different micro-APIs at the same time.

This means that runtime engines can be distributed to servers across the world and function as a content delivery network for your API. API requests are handled by the servers closest to the client. Having such a network of servers makes Scaling server-side logic as simple as static content distribution. Thousands of requests per second can be serviced by simply increasing the execution engines.

However, the micro API has the disadvantage compared to other serverless environments of having dependencies and a framework to manage, which limits the choice of the execution engine. This limitation however has a silver lining. It allows the developer to focus on the business logic and launch many APIs without worrying about the architecture.

But for which tasks are micro APIs suitable? There are different possible uses. You can use it for a proxy API that spans another API to bridge data format differences or Authentication protocol. It could be a webhook receiver that checks the data before calling another API, a router for a Microservice architecture or an API that combines data from several other APIs.

Lukas concludes by saying that you should think of a micro API as a glue that will tie two things together in a way that makes building and deploying code easy and free.


Leave A Reply