0

I have seen multiple videos on microservices from guys building netflix/instagram and so on, and many and data consistency between microservices, but one thing that I can't really grasp yet, is as simple as responding back to frontend.

Let's say we have frontend SPA or it could be anything else. The frontend has 2 approaches to get data (from my POV) - either it calls multiple APIS on different microservices, or calls a one that needs to orchestrate other microservices to compose a complex response.

The frontend creates an http request to one single microservice as per REST practices lets say it calls GET on service 1. To get a reply, this service 1 needs to call services 2 and 3. Since the best practice says to not use HTTP requests between the microservices but Asynchronous approach such as some message queue - this takes some time but does not block the HTTP request in any other way.

My question is - how to approach this timing incosistency? Because in this case, service 1 could easily continue its evaluation of source code, and the message from MQ could get back later than it has already replied back to frontend, at least thats what I think. Or should we block http request for some time until we get the response from MQ and check some list/cache which was set by the response from otherservice via MQ?

Or this approach is bad and it either should be that frontend calls multiple microservices' api - or the communication which needs to return something to frontend should be RESTful e.g. blocking even between microservices?

Or maybe I misunderstood and the microservices should be so self-sufficient that they don't talk to each other at all?

Pic to see how I imagine it

Thanks for helping out

3
  • A few comments. Your frontend communicates with the microsvc-based system by invoking an API (or several APIs) - which is (or, in case of several, which are) just a set of rules for exchanging messages; whether that API is (or, whether those APIs are) implemented (or served) by 1 or 15 different microservices is none of the frontend's business. Design the kind of API that serves the client's needs; the processing time of course influences what the API will be, but the exact mechanism by which processing happens has nothing to do with the API or the frontend. 1/2 Oct 25 at 22:41
  • Think of the system as a of a black box (or... a nebulous cloud, I guess) from the frontend's perspective. If you have exceptionally long running tasks, you might use something like SignalR or Socket.io or some such WebSockets-based framework to notify the client (you might have a dedicated notification service). If microservices don't talk to each other at all in any way, then they are just separate small (and potentially useless) services. Now, it's true that you don't want them to be too chatty either (because of latency issues), so there's a balance to be found. 2/2 Oct 25 at 22:41
  • First of all: when you say that the http request is not blocked, this is not a general rule. You may well implement a request-response pattern and have the frontent wait synchronously. Then, if your microservice needs to call two other services to operate, it is probably not a good cut of responsibilities. It should be able to do meaningful work standalone.
    – mtj
    Oct 27 at 6:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.