This is the second part of a series on “Moving from RESTful to EVENTful.”
As I see more and more companies working to add event-driven, sometimes called “real-time,” APIs to their programs, I am noticing that there are common cases where an event style is favored over others. Using Martin Fowler’s names as a reference point, I’m noticing that event sourcing (ES) and command-query responsibility segregation (CQRS) are the most commonly discussed event styles right now. However, I am also seeing a couple less intensive (and just as valuable) event styles with event notification (EN) and event-carried state transfer (ECS) implementations. I like the notification and carried state patterns because they are relatively easy to introduce into an existing RESTful system and offer quite a few options for both implementation and consumption.
In this installment of “Moving from RESTful to EVENTful” let’s explore the simplest of these four styles: event notification and see how it is often used to enhance RESTful implementations.
Anatomy of an event notification
So, what does an event notification look like? As you might guess ENs are typically simple strings that announce actions or events within the domain. For example, “Your package has been delivered” or ” Server q1w2e3 is running out of memory” and so forth. These are the kinds of messages you’ve come to expect to appear on your mobile phone or as a “system pop-up” on your desktop interface. They are essentially alerts.
And, list most notifications on your phone or desktop, ENs that are used in machine-to-machine API interactions carry a simple message. One that someone else (or some other machine) wants to know about or is tasked with dealing with. That’s a key element of ENs: they have a target audience.
Another important aspect of ENs is that they don’t carry much detailed information. You might, for example,. Get a notice on your phone that one of your servers is performing badly but that notice will not have details on what the problem is or when it started. For that, ENs usually contain links that point to a more detailed and definitive source of information. So, along with a descriptive string, ENs usually contain a link to another resource.
Finally, ENs may contain a date-time stamp to add some context to the message. This helps if, for example, you are collecting and storing the messages for later review.
So, if ENs just have simple strings, a date-time, and a link, what makes them useful in an enterprise IT system?
Alerts and nudges
While ENs are very simple, they can have a great impact on your software architecture; for both client-side and server-side applications. In fact, it is quite likely that you are already using some version of event notifications in your apps.
A great example of client-side even notifications is the use of desktop and mobile pop-up notifications. These are short messages that remind you to pick up a loaf of bread at the market, check on the status of your social network feed, or prepare for that meeting that is about to start in five minutes. One the client side, ENs are often used as “nudges” to encourage user interaction and engagement. Adding these to your own client-side applications can improve user experience without adding a lot of burden on your system.
A very common server-side example of ENs is the use of tracking and logging messages for your services. Most platforms have some form of collecting key actions within services like user logins, shopping cart check-outs, and completed forms. Often these actions are business-level indicators of success (shopping checkout) or failure (abandoned purchases). ENs like this are essentially alerts and are typically displayed on live dashboards at various places within the company to track the health and welfare of the IT side of the business in near-real time.
Server-side alerts and client-side nudges are great ways to improve the engagement and observability of your system without having to do much re-engineering. Often, server-side alerts can be treated as an add-on to existing systems without rewriting code. Client-side ENs often require additional coding so that client apps can listen for, and respond to the messages when they appear.
Summary
As you work to add more support for EVENTful interactions to your platform, event notifications are a great way to start. They often require limited investment and can provide valuable feedback. Since EN are often just alerts and nudges, you can introduce them to your ecosystem without requiring changes to your data models, object interfaces, or workflow processes.
The next step on the journey from RESTful to EVENTful means leveling up on the content of your messages. In the next installment in this series, I’ll talk about how you can use more detailed messages to carry stateful information along the network to improve your system’s workflow flexibility and responsiveness.
To see how MuleSoft supports event-driven patterns using a reactive engine, check out our Mule runtime engine.
