1

I am interested in microservices and SOA. I read some tutorials. This is my understanding SOA. The API gateway receives lots of requests (requestA, requestB, ...) and put requests in messaging queues. Micro-services will consume the events in the messaging queues and do some processing. My question is after processing, how the response can be returned to requests (responseA to requestA, responseB to requestB).

I am not sure whether my understanding is right or wrong and whether messaging is used in every architecture.

Anyone can give me more details/examples how to decouple/connect the API gateways and the microservices. How to respond to requests? should the connection between API gateways and clients kept alive?

Sorry if my question is not clear. I am confused and have no idea how to understand each concept.

Any comment welcomed. Thanks

BAE
  • 8,550
  • 22
  • 88
  • 171
  • your understanding is wrong, there is no queue, you just send 1 request to microservice and wait for response, thats it, nothing more – Iłya Bursov Aug 11 '17 at 19:59
  • Messaging is one method to do communication between micro-services, REST API is another way. In the case of messaging queues, I wonder how to match request and response. I am interested the details how to implement this kind of communications. – BAE Aug 11 '17 at 20:19
  • if you want to get response for your request - you're either waiting for it explicitly or you can use queue to do asynchronous evaluation (I'd not say that it is another way of communication, it is different application architecture and design), in this case people usually generate some id in message, later this id will be used by server to send message back into _another_ queue, so client can pick it up, there are could be other ways to notify client about result – Iłya Bursov Aug 11 '17 at 20:28
  • Thanks. I am really confused by `how client can pick it up?` keeping connection alive all the time? websocket? – BAE Aug 11 '17 at 22:26
  • Technically websockets are based on constantly opened connection, yes, it is one possible variant for client to constantly wait for messages from server via keep alive connection. Another way is to perform periodical pull from some source (DB, queue, other server), another way is to listen on some port, so server will open connection to client and notify about response. – Iłya Bursov Aug 11 '17 at 22:34

2 Answers2

0

API Gateways and queues are not really key here (this is your implementation detail for microservice).

As @Ilya Bursov pointed out what you are looking for is either HTTP polling (repetitive checking if response for your request is already available) or websockets .

You can find more details here My Understanding of HTTP Polling, Long Polling, HTTP Streaming and WebSockets

Lech Migdal
  • 3,828
  • 5
  • 36
  • 63
-1

MicroServices simple independent units communicate with message broker ,read a requirement message from its own queue and send the response to the message broker again ,which broadcast the same resposne to all the other queues.

API Gateway provide rest API and post a requirement message to message broker , that message will consist of details required by microservice to process a request, also has its own unique queue which is binded with message broker and once a message arrive which has a solution for specific request ,it will respond back to the client.

Vijay Parmar
  • 795
  • 4
  • 13