Data either flows or rests. When data flows, it can travel fast or slow and over various types of structures and patterns. High volume (fast) data travels via asynchronous messaging mechanisms, whereas low volume (slow) data is handled with synchronous, request-reply mechanisms.
Trading floors, for example, require high-performance/low-latency data channels in order to broadcast millions of stock ticks per second. Conversely, a customer service agent collecting info about a caller’s account from a variety of aggregate sources is typically called via a request-reply API, and doesn’t typically occur in a large volume context.
Synchronous patterns are often represented by RESTful architectures, whereas the asynchronous patterns are reflected by EVENTful or event-driven architectures. Event-driven architectures are designed to handle longer running business transactions through choreographies (rather than orchestrations). They are more flexible and extensible than their RESTful counterparts and have additional benefits like loose coupling and linear scaling.
In the remainder of this article, we’ll explore some of the challenges that come with implementing an event-driven architecture and what solutions can help overcome them.
Challenges with event-driven architectures
While there are incredible benefits that come with an event-driven architecture, there may also be some shortcomings. The RESTful world has comprehensive solutions for API lifecycle management, as well as platforms that offer complete governance and operational control over RESTful APIs. The EVENTful world has yet to catch up.
Below are some of the key challenges with event-driven architectures that pertain to API lifecycle management:
- Specifications: Whereas a RESTful approach has had specifications available for a while (SWAGGER/OAS, RAML etc.), the EVENTful world has only recently begun having specifications.
- Discoverability: RESTful APIs (and associated schemas) can be published to a catalog/app store, there are no API/event catalogs yet for EVENTful categories.
- Developer experience: When working with event-driven architectures, developers need to work with multiple protocols (JMS, MQTT, AMQP, Kafka, etc.), which can be challenging.
- Testability: Unit tests and test-driven software development approaches have yet to be developed for EVENTful approaches.
To overcome these challenges, evented APIs were conceived. Evented APIs address many of the challenges facing the event-driven architecture dimension and create better operational alignment with RESTful approaches.
How evented APIs solve these challenges
Evented APIs arose as a way to bring a similar level of governance to the EVENTful world that already existed in the RESTful world, and to make the experience of the API consumer similar as well. Let’s explore some of the aspects of evented APIs:
Specifications
Evented APIs can be defined using the AsyncAPI specification. The AsyncAPI specification allows users to:
- Use “publish” and “subscribe” as core verbs (similar to GET, POST, PUT, etc. of HTTP)
- They use “channels” to identify the medium of transport for events.
- Channels are associated/bound to servers, where servers are protocol brokers such as JMS, MQTT, Kafka, etc.
- Event schemas, defining the structure of the event payloads going across the channels.
Discoverability and testability
AsyncAPI spec and event schemas can be published in a catalog/app store to facilitate discoverability and reuse — addressing one of the event-driven architecture gaps. Once an AsyncAPI is published, mock tests can be created to reflect the utilization of the API, removing the testability gap in event-driven architectures.
Standardized developer experience
Once an AsyncAPI spec is defined, the developer can implement the actual API. Using a “code generator” tool, a skeleton/scaffolding for the API can be generated in a particular programming language (i.e. Java, Node, Python, etc.) or an integration domain-specific language (DSL), like MuleSoft. The generation process should create “generic connector interfaces” that abstract knowledge of the underlying transport. The idea being that a developer only needs to work with the verbs (publish/subscribe), the channels, and the event schemas. This “generalization” eliminates the need to understand the configuration and binding semantics of messaging protocols.
API security
The remainder of the evented API lifecycle (manage, secure, consume) follows the same pattern as RESTful APIs, with one other difference being when dealing with the security aspect. Whereas RESTful APIs need to apply policies to a single endpoint, evented APIs will need to apply security policies at both the publishing and subscribing end of the channel.
In short, modern platforms will aim to provide a unified experience for managing the lifecycle of both RESTful and evented APIs.
Summary
In an article published in 2017, it was stipulated that by 2020, 50% of the managed APIs will be evented. With the rise of IoT and cloud messaging, the number of use cases and event-driven architecture patterns has increased exponentially across all industry verticals; as such that prediction has indeed come to pass.
In short, with evented APIs, organizations will be able to manage asynchronous APIs in the same fashion as one does with synchronous APIs, thus making the two paradigms fully compatible with each other. With evented APIs, managing “Fast Data” over a heterogeneous event fabric will be significantly better than it was in the past.
In the remainder of this series, we will explore how evented APIs are being applied across a number of industries. To learn more about how to manage the full lifecycle of your APIs, download our eBook.
