Chances are, you have as many events flowing through different channels as APIs. Maybe more. There are probably even more message producers and consumers than API clients. Most likely, the messaging infrastructure you’re using is not providing enough control and visibility over what’s happening. If it does, you can stop reading now.
Still reading? Good. If you’re interested in a possible solution, API management can provide it. You can use the same toolkit you know from applying runtime governance and getting analytics for your APIs for events also. Here’s how.
Simply put, we’re going to stick the API Gateway between the producers and the message broker like we do with API clients and APIs (backends). Let’s take it step by step.
Our starting point is very simple. We have a single message broker and we’ll have a simple producer and listener implemented to see how things work. In such a scenario, event producers would publish their data to the message broker for event consumers to retrieve them.
As I said, we’re going to place the API gateway between the producers and the message broker. With synchronous APIs we do it in a way, that makes things transparent for the backend (the actual API implementation), and we’re asking the API client to use the gateway URL (e.g. http://gateway/api/product/) instead of the backend URL, which may be very different (e.g. http://backend/services/public/product).
Here, in asynchronous scenario, we’re doing a very similar thing. We’re asking the message producer to publish the message to a different (gateway) channel while we configure the API gateway to listen to it, do the gateway thing when a message arrives, and then forward it to the actual channel, from which subscribers are consuming the message. For example, in the picture above we have producers publish messages to an “event” channel (topic, queue, etc.) from where subscribers consume it. The picture below shows how it’s going to be when we proxy these events via an API gateway. We’re asking producers to publish messages to an “ingress” channel. API Gateway would listen to this channel, fetch messages, apply runtime policies and forward the message to the original “event” channel from where subscribers would consume it.
The “ingress” channel in this asynchronous scenario is an equivalent of the gateway endpoint in the synchronous scenario.
- Connect the API Gateway to a message broker.
- Create an API, which would listen to some channel and forward the message (using a routing policy).
- Set up your policies as you normally do.
There’s more details for such a set up in a related article about API Gateway support for protocol bridging.
Watch this demo if you want to see it in action.
While we’re getting a lot of value from such an implementation in terms of governance, control and visibility there’s a cost to it as well. Just like with synchronous APIs, except for one case (results caching), API gateways do not make APIs respond quicker. They need time to process the API call or event and that should be added to the overall time it takes to call an API, send or receive a message. It also adds additional component to the architecture. Is it worth it? I think so, especially when governance and visibility are important to you. I’ll let you be the judge for yourself. Feel free to comment below.