Implementing event-driven capabilities through existing APIs

In current technology growth, APIs are the standard for building and connecting modern applications. They provide a standardized interface that masks backend complexity and makes it simple for an enterprise to secure, monitor, and manage how the digital assets it shares are used. Below, we’ll take a look at the differences between RESTful and event-driven APIs, an overview of event-driven architecture, and how to implement event-driven capabilities into existing APIs.

Event-driven design: The power of event notifications

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.

Moving from RESTful to EVENTful

For close to twenty years, the “common standard” of APIs on the web has been summed up in one word: “RESTful.” Designers, developers, and software architects have promoted, debated, and derided the notion of RESTful APIs in successive waves over the years with all sorts of pundits declaring REST “dead” and offering some other current practice as “the new REST” or, even better, “the REST killer.” Probably my favorite rejoinder in this space is Matt McLarty’s “

How to augment API elements from event-driven architecture

Many organizations undergoing digital transformation are under pressure to connect their applications, data, and devices — most often the path to success is moving to an API-led integration strategy.

How to mitigate unhappy paths with an event-driven architecture at scale

The reality of supporting production event-driven architecture at any reasonable scale is that it can be challenging, especially when dealing with bad events and unhappy paths, both of which affect business operations and the customer experience. Architects and developers often focus on delivering the minimum viable product (MVP) to show business value early and validate the approach taken. While focusing on the MVP can be valuable in establishing IT agility — the requirements are targeted at normal operation,

An event-driven approach to Salesforce integration

A number of the materials (posts, tutorials, etc.) available out there present an approach to integration between MuleSoft and Salesforce on the basis that MuleSoft is always proactively responsible for starting communication, injecting or pulling CRM data based on a schedule or otherwise. 

This post aims to present a different approach to integration between these two platforms, where MuleSoft works in a more reactive way, triggered by notifications (events) sent by Salesforce representing new or modified data,

How to design message-driven and event-driven APIs

Asynchronous messaging is critical to creating a truly scalable system, where various services can communicate with each other easily, can scale up and down independently, and where one service failing won’t cause all the other services to fail. With the trend of microservices in full swing, this has become even more important. As Tim Bray from Amazon stated: “The proportion of services I work on where queues are absolutely necessary rounds to 100%.”

Event-driven architectures and the AsyncAPI specification

September 24 2019

0 comments

I’m at the Barcelona airport. It’s summer and I’m finally going to visit my family in Badajoz after a long period. The queue at the security checkpoint looks endless but I have time. The phone rings. It’s my mom, she’s excited that I’m visiting and is giving me an update on how things are there now.

Middleware is dead! Long live the application network!

November 24 2017

0 comments
application networks

Once upon a time, I couldn’t do without my middleware. To make my application resilient and scalable, and to allow it to talk to everything else in the enterprise, I had no choice but to stand up an ESB in my architecture. It was literally in the middle of everything I did. Then, when I moved to the cloud, my world began to change.

Twitter Complex Event Processing (CEP) with Esper and Drools

February 8 2012

9 comments
motif

Complex event processing engines are a natural fit for event driven platforms like Mule. Native  CEP support has been available in Mule since version 3.2 by way of the Drools Module.  The Esper Module now offers an alternate way to leverage CEP in your integration applications.   Esper is a robust, performant, open source, complex event processing engine.  Let’s take a look at how to use Esper with Mule and then see how it compares to Drools’