3

I basically have a smaller software that is using the Microservice architecture. I am currently using RabbitMQ to do the communication between UI and services and that works great.

However I am thinking about creating a new microservice, a API Gateway, that basically takes the RabbitMQ logic from the UI and encapsulate into a service, which would become the entry point to all the other services.

The benefit is that I would encapsulate the logic that give access to the services and also being able to add authentication in the API Gateway.

However I would need to use HTTP request to interact with the API as I am moving the messaging logic from the UI. Could there be any major drawbacks in this approach?

I have being able to find examples about RabbitMQ and examples about API Gateways but never those two together, I might just be overthinking it a bit.

lifeisfoo
  • 15,478
  • 6
  • 74
  • 115
codingcow
  • 31
  • 5
  • If you don't need a API on top of your system for people to access I'd just stick with RMQ – Kevin Smith Mar 14 '18 at 16:21
  • @KevinSmith I am also just thinking that there is a high possibility for new UIs to be created, then by having the API Gateway I could encapsulate the RabbitMQ calls from all UIs. – codingcow Mar 15 '18 at 07:29
  • As you mentioned if "that works great" let it be as long as you dont have some new requirement which can not be handled with current approach. A couple drawbacks come to my mind especially regarding the message reading side. I am curious how do you handle it now and how are u planning to handle it with rest? – cool Mar 16 '18 at 11:21

0 Answers0