Software development has moved quickly in only a decade. From deploying to physical servers, to virtualization, and IaaS to PaaS. One hot trend is FaaS (function-as-a-service), like AWS Lambda, where you deploy snippets of code to be run on command anywhere in the world. The latest development, however, is the Micro API, which builds on serverless computing and FaaS to take API development to the next level. Lukas Rosenstock over at the CloudObjects blog introduces the concept.
Lukas defines a micro API as a design pattern for a piece of software that meets the following criteria. It exposes a web API (e.g REST) to a client in a single file with only a few lines of code. This file relies on a standardized framework and set of dependencies and has no local state.
Anything that fits this criteria can be run in an execution engine that provides the relevant framework and dependencies. The small amount of code then means that it can be deployed on demand. A request comes in, the code is fetched from a repo, cached within the engine and executed. An execution engine can be multi-tenant, meaning it can be running many different micro APIs at the same time.
What this means is that execution engines can be distributed to servers across the world and function like a content delivery network for your API. API requests are handled by servers closest to the client. Having such a network of servers makes scaling server-side logic as easy as distributing static content. Thousands of requests a second can be handled by simply scaling up the execution engines.
The micro API has the disadvantage over other serverless environments, however, that you still have dependencies and a framework to handle, which limits the choice of execution engine. This limitation has a silver lining, though. It allows the developer to focus on business logic and launch many APIs without worrying about architecture.
But for what tasks are micro APIs suited? There are various possible uses. You could use it for a proxy API that covers another API to bridge differences in data format or authentication protocol. It could be for a webhook receiver that checks 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 you should think of a micro API as glue that will connect any two things in a way that makes code creation and deployment easy and free.