| Adopting a microservice architecture does nothing to define how you "render your output"- the devil is still in the details, but that is why a microservice is so interesting and flexible. The way you will tackle this will largely depend on many questions like what services are safe to be exposed publicly, what services are dependant on other services, do you have a public API? For example, you could have a public facing API on each service, or endpoints that render HTML templates. The services may or may not talk amongst themselves, either via the same public API, or a private one. If you make a request to one of the services, and that service needs to make a request to another service to generate the response, you've got to make a call on whether you want a blocking or non-blocking approach. Consider: 1) Blocking until the other services have responded 2) Pinging the server to check when it's done 3) Using web sockets 4) Whatever the hell else you can think of Alternatively, you might want not want to expose your services publicly, and choose to have a single service that talks to the services on the clients behalf, a middleman. Your client speaks to this service, and the service sends of various requests to the other services. But the problem still stands. To block, or not to block? AFAIK some big names like Amazon, Spotify, (Twitter?) have multiple public services. You may sometimes notice individual components on their [web] applications failing without bringing down the whole site, since the failures are isolated to the different services. Neat, huh? |