Did You Get That Thing I Sent To You? – The Rise of Event-Driven Architecture

They say that there are two certainties in life: Death and Taxes.

I would pose that there is one more that permeates the world of technology, and that is “trends.” Far too often, popular methodologies or frameworks are adopted quickly and often without proper research to back up their need.

The tech world is quick to sell potential users, adopters, and investors on “names” that comprise elements of their stack, sometimes with no regard for the downsides that come with incorporating these popular libraries or technologies into their codebase. 

A good example of this might be Blockchain. Now that’s not to say that the cryptographic digital ledger doesn’t deserve its time in the spotlight for the way it has revolutionized cryptocurrency or FinTech as a whole, but when passerby’s at a Trader Joe's ask, “do you use Blockchain,” things have gotten a bit out of hand.

It’s not that tools like Blockchain shouldn’t be revered for what they do well, it’s more that a name has become synonymous with “cutting-edge” and evokes a sense of competency from outsiders that may not know the tool’s purpose in the first place.

More examples of trends that have become huge recently would be big data, containers, and even microservices, which I recently wrote an article on here. All of these tools and technologies provide wonderful functionality when applied to the right project, and should be thoroughly revered for the success that they can bring to a codebase. 

Most recently, I have been singing the praises of another “trend,” which I feel is a wonderful breath of fresh air to those of us in the API development community: Event-Driven Architecture (EDA).

What is EDA?

Representational State Transfer, or REST, architecture has been the driving force behind API architecture for almost the last 20 years. REST is transported over the HTTP network protocol and relies on a system of synchronous requests and responses. Essentially, a request is sent from a client to a server, which then parses the request and issues a response. RESTful architecture allows for APIs to harness a transport layer that can be used with any programming language, a point that helps to explain their massive permeation in the world of API creation.

The popularity of REST architecture came about as a result of a driving need for the exchange of data between the client and the server sides. REST integrated with JavaScript easily and was easier to implement than the prior SOAP architecture, so it was of no surprise that it became so heavily adopted very quickly. Web servers like Express, development frameworks like Node.js, and security frameworks like OAuth meant developers could easily implement large chunks of their application’s architecture easily with these readily available tools.

However, now in the age of constant notifications, both within applications and facing their users externally, there are plenty of requests that don’t actually need a proper response. Confirmation that the request has been received is plenty in many situations. This is generally referred to as “fire and forget,” and serves the purpose of simply acknowledging that a request was received by the server. Essentially, if no “asset” is being requested, then there is no need for a response. Some examples of this are an application being alerted to a new user signing up or letting a user know that they have a new follower on a social media platform. These are relayed as events or, sometimes referred to as, messages.

However, often there is extra information that would prove helpful if attached to that event, but a full-on response from the server is not necessary. These are referred to as “event payloads.” Examples of event payloads relating to the above examples would be relaying the basic information of the user that signed up, or sending along the details of the new follower such as their username and profile picture.

In order for these messages to be relayed, something called a Message Broker is put in place. A message broker is a form of middleware that mediates communication between applications. The application that is being accessed and sending out a message is called the Publisher, and the application receiving the message is called the Subscriber. Examples of popular message brokers are Kafka, ActiveMQ, and Redis, although Microsoft has rolled out an easily-scalable offering that is gaining popularity with their Azure Event Hub.

Built for Event-ual Success

At this point, it should be quite obvious that there are applications that can specifically benefit from EDA due to the nature of their functionality. One such sector that is leveraging this application design pattern is the Internet Of Things (IoT). With the popularity of Ring doorbells, Nest thermostats, and similar gadgetry in our homes, it is easy to see how EDA can benefit the applications that drive these products. If your home reaches the optimal temperature, an event can be triggered alerting your smart thermostat to stop heating. If a motion detector is triggered on your smart doorbell, an event can be fired off instructing the camera to begin recording your visitor.

The benefit of EDA for IoT is the nature of generic events. Each individual gadget is operating under a unique identifier, yet the messages that accompany the events are applicable to each and every user of the hardware. You might set your optimum temperature to a different level than another user, but when the event is triggered, your messages will be identical save for the temperature parameter that the event is triggered by. This simplifies the nature of relaying events, as a single event listener can kick off the message broker’s default event to be delivered to the subscriber.

Future Development

While EDA is not an entirely new concept, it is still playing catch up to the available toolsets and foundational components that are widely available to REST architecture. Message brokers like the ones listed above and security frameworks like OAuth are being heavily implemented and developed for, and recently there has been an emergence of development frameworks to ease the burden of writing event-driven microservices. Spring Cloud Stream is one such framework created to help build highly scalable event-driven microservices connected with shared messaging systems.

A major driving force for aid to those embracing the EDA design in their application is the introduction of AsyncAPI. Much like OpenAPI, AsyncAPI aims to standardize the way event-driven API interactions are managed and provide support for the wide variety of messaging systems available today. AsyncAPI enables architects and developers to specify a wide number of different definitions including event payloads, channel names, application headers, and more. 

AsyncAPI hopes to implement one of the more powerful tools available to its RESTful cousin, OpenAPI, with code generation tools. Similar to how OpenAPI generates interactable documentation for REST APIs, AsyncAPI is working on the ability to translate definitions into the generation of full event-driven applications through the use of Spring Cloud Stream.

EDA’s popularity has skyrocketed due to the need for real-time eventing in so many modern applications, as well as the ability to fully decouple systems involved. In order for EDA to proceed at the level of growth they are experiencing though, more available tools for eventing must continue to be built and supported. 

When deciding on what’s best for your codebase, remember that the interactions that will take place should drive your use of a specific type of API architecture.