API gateway for event-driven architecture

6
votes

We're trying to split our monolithic core into microservices and add some new ones connected with each other using the message system (e.g. Kafka).

The next stage is to create API endpoints for communication between mobile apps and microservices through Api gateway.

What would be a good solution for developing API gateway to transmit data to/from microservices?

  1. use message system as request-reply one (transform requests on API gateway into message commands, wait for response from message system with status or necessary data)?
  2. create REST endpoints on necessary microservices (e.g. using REST.li) to send or get data through gateway; use message system for consistency of data based on produced events by microservices?

Thanks for advice and some ideas

2
restsoamicroservicesevent-driven
Facing the same problem. I have several services talking over rabbitmq. I need a gateway to interact with the system. Interested to know what solution you arrived at? – marcin_koss

2 Answers

0
votes

I would like to say that the second option sounds more reasonable for many cases.

Event-Driven solution mainly fits in the cases in which there are several following processes, so the creating entity could be via Rest endpoint, while processes of that entity could be async via events.

To illustrate, Payment Flow could be like below:

1-) API GW -> Payment Rest Controller -> Payment Service - Create Payment Payment service creates a payment entity, and then publishes "payment.created" event. 2-)Queue -> Payment Stream Controller -> Service - Update Payment Payment Stream controller consumes the "payment.created" event, and then checks balances, and updates payment entity as Confirmed. After updating the entity, it could send "payment.confirmed" event. ...

On the other hand, I mean the first option, it would be very hard to maintain a very decoupled system, as you need to know all exchanges or queues.

However, I think combining two solutions could be better for some cases. For example, your API is exposed by a client with very high traffic and the task of the API is quite clear. In that situation, using MQ as a buffer for this API would be perfect.

-1
votes

This depends about the Architecture that you are adopting. If I understood the question, you already have the broker with the kafka message server. I think that you can use the architecture publish/subscribe to assyncronous message.

If in the backend architecture the legacy systems to support SLA, in this case you can use the rest endpoints necessary to the integration.

This is the gain of if to utilize API Gateway Pattern in the Architecture.

Thanks a lot.