10 FAQs About Event-Driven APIs
Here’s a compilation of frequently asked questions about event-driven APIs (also known as asynchronous APIs or reactive APIs). Review their role in event-driven backend architectures and how they can be managed with standard API management tools.
1. “ Is an Event-Driven Architecture (EDA) worth the complexity that comes with it?”
An EDA is not the right answer for everything. Sometimes a simple call from one service to another is enough. And because processes must handle eventual consistency, duplications, or out of sequence events in EDAs, this can make service code more complicated and harder to test and debug. Therefore, it’s critical to evaluate the interactivity and interoperability required by any given use case to determine if an EDA is really called for. It may require too much troubleshooting and maintenance to be used in situations that simply don’t need it.
But if there are existing pains in the organization, such as significant outages — especially when it comes to scaling applications (e.g., if you are using traditional APIs around legacy systems and those are exposed to web channels and those web channels have increased in volume), or if there are general issues around robustness, reliability, uptime and response time, an Event-Driven Architecture can be a game-changer to resolve those pains.
2. “How can I merge an API-led design with an Event-Driven Architecture (EDA)?”
With event-driven APIs! The remote event connection between the backend and web clients can be established via event-driven APIs powered by various asynchronous API technologies (such as Webhooks, WebSockets, Server-Sent Events, GraphQL subscriptions, etc.) depending on the exact requirement. The backend uses the remote channel to send events relevant to the web clients. Additionally, this remote channel allows the back-end services to receive events that originate from web clients.
An event-driven API requires two capabilities — a mechanism to allow a consumer to subscribe to an event and the means to deliver events to the subscribed consumers. The event-enabled APIs can connect to a message broker and consumers can subscribe to a channel of interest via the asynchronous APIs. While event-driven architecture does not explicitly require the use of middleware, using an intermediary (a message broker) between event producers and consumers helps to implement corresponding patterns and deliver more manageable and scalable solutions. A few notable examples of brokers are RabbitMQ, Apache Kafka, Apache ActiveMQ, and Solace PubSub+ among many others in the market today.
The broker can receive events from IoT devices, other back-end systems and services (and also from the event-driven APIs if two-way communication is enabled) and alerts the services that subscribe to those events. A scalable microservices architecture (MSA) is the optimal architecture for complex event-driven back-end services. These event-driven microservices can behave as event subscribers or publishers to process events, handle errors and persist event-driven states.
3. “What is the reason for the rise of event-driven API architectures?”
With hyper-reactive UIs and the wide adoption of microservices architecture (which performs really well with event-driven concepts), the adoption of asynchronous APIs also spiked. Digital enterprises are looking at eventing as a way of solving the real-time interactivity needs of their consumers. Event-driven APIs enable that along with other event-driven components of your backend. Being event-driven is about moving towards real-time and taking advantage of events as they happen. For example, if I type something on a website, and the company that owns that website can do something relevant and meaningful for the user in that second as it happens, that’s powerful.
4. “What are some use cases that are best suited for event-driven APIs?”
If you are building applications that need to be updated in real-time or near real-time, and are based on events, you’ll want to use event-driven APIs. In a majority of APIs today, the client initiates communication by sending a request to the backend and waits for a synchronous response. This is not ideal for scenarios that have UI components that are updated based on back-end state changes. Waiting for a synchronous response is not scalable because it ties up resources on the back end, as well as communication with the client. Event-driven APIs have emerged to address these problems. Here are some instances of event-driven APIs in action:
- Receiving notifications about someone liking your picture on Facebook
- Receiving notification about someone reacting to your story on Instagram
- A new Whatsapp message
- A stock ticker displaying price changes in stocks
- A social stream (e.g., your Facebook news feed displaying the latest updates from your friends)
- Live transit updates in transportation scenarios
- Live sports score updates
- Chat applications
- Video games
- Live collaboration scenarios (e.g., a few people updating a document or spreadsheet)
5. “Which protocol(s) is/are best suited for event-enabling APIs?”
The asynchronous protocols commonly used today solve the problem of real-time communication, but they solve different aspects of this problem in different ways, thereby making some protocols serve different purposes better than others.
- For multiplexed, bidirectional streaming, and for applications that need a huge amount of messages from both ends of the connection, WebSockets is ideal.
- MQTT is more suitable for IoT devices with limited battery life.
- Server-Sent Events are especially useful in cases where a browser client is just interested in subscribing to a stream of data without needing to communicate back with the server in the same connection.
- Webhooks can be used for a simple implementation of pushing notifications to one or a small number of servers.
- The newer async variants of GraphQL (Subscriptions and Live Queries) come with the benefits associated with GraphQL, the implementation is relatively complex and entails a significant learning curve.
- gRPC and Kafka are mostly used for communication between internal microservices.
6. “What is the AsyncAPI specification and how is it different to the OpenAPI specification?”
AsyncAPI is to event-driven APIs as OpenAPI is to REST APIs. AsyncAPI is designed along the same elements of the OpenAPI specification to standardize event-enabled APIs. While AsyncAPI shares many constructs with OpenAPI to simplify the adoption, it also comes with additional features to support a wide variety of messaging protocols and transports (such as AMQP, MQTT, WebSockets, Kafka, JMS, STOMP, HTTP, etc.), and event schema formats. Therefore, the API definition will contain the event payload definition, channel name, application/transport headers, protocols, and other eventing semantics to connect, publish, and subscribe to the API.
7. “Do API gateways serve any purpose in the world of event-driven APIs? ”
At the moment, support for asynchronous APIs in API management solutions is limited. But API gateways can play their designated role with event-driven APIs that communicate via web-friendly protocols, such as WebSockets, SSE, Webhooks, and the GraphQL variants (but not protocols like MQTT or Kafka). Numerous API management solution vendors are looking at various ways of accomplishing the task of efficiently managing event-driven APIs in a gateway-centric way. Here’s one way to do it:
API developers can leverage the AsyncAPI specification to document event-driven APIs and publish them to the developer portal. When an application developer discovers and subscribes to an event-driven API (or an event) in the developer portal, there must be a mechanism for the message broker to be configured with the correct access control lists, internal queues, subscriptions, and various other settings to ensure the secure delivery of the selected data streams via the broker and API proxy (in the gateway) to the developer’s application directly. And during runtime, the API gateway will receive and emit events. It will handle the runtime proxying of service requests and responses, and perform authentication, throttling (to a certain extent), logging, mediation, and transformation by communicating with other key components such as the security, throttling, and analytics components of the API manager. It can also provide ways to enable commercial models around the APIs. Read more about event-enabling API management here.
8. “Can REST APIs and asynchronous APIs coexist on API marketplaces/developer portals ?”
Yes, they can. For example, WSO2 API Manager allows event-driven APIs and REST APIs to be advertised on the same developer portal. It allows you to view your REST APIs, GraphQL APIs, and Websocket APIs all on the same developer portal.
API developer portals, separate from API gateways, resolved problems around documenting, governing, monitoring, and collaborating on APIs. For event-enabled APIs, the portal can be used to advertise events and their schemas(based on the AsyncAPI specification) along with REST APIs (based on the OpenAPI specification). The ability to have a single place to catalog and advertise REST APIs alongside a taxonomy of events can be beneficial or even critical to some organizations.
9. “AsyncAPI is leading the way but why are tools for asynchronous APIs so late and under-equipped compared to synchronous APIs ?”
Even though the concept of event-driven architecture is not new, event-driven APIs relatively are. REST APIs had been more widely adopted with a variety of API management tools supporting them before event-driven APIs emerged. Now the AsyncAPI initiative is pioneering the effort to standardize asynchronous APIs. It’s also important to note that asynchronous APIs are more complex/different compared to REST. Unlike the REST-fashioned APIs, which follow the same basic patterns (GET/POST/PUT/DELETE) over HTTP, there are multiple approaches to push/streaming over different protocols that feature some significant differences from one another. So, documenting them, generating client code, and producing other tools require a considerably larger effort.
10. “What are some emerging trends in this space?”
The trends to look out for are further enhancements to event-driven API technologies and the AsyncAPI initiative, how everything will be working in a mesh architecture, such as event meshes and service meshes, and tooling and API management for event-driven APIs.
Further Reading
A few more articles about event-driven APIs written by me:
