In the old days we used to create a single .gif file for the entire application to avoid too many trips from the browser to the server. Similarly, we used to combine different types of information in a single response to avoid unnecessary HTTP traffic.
Did all this change with the microservice paradigm? Is it better to have small, independent services invoked from javascript? Is it better to have clear, loosely coupled HTTP requests/responses than to minimize traffic?
One thing hasn't changed: the speed of light. E.g. when I send a HTTP request from Europe to a server in New York, I'll have a round-trip latency of at least 60ms. Opening a TCP connection and negotiating TLS encryption needs additional roundtrips, so we are looking at ~200ms latency for the first request to a server. And that excludes DNS lookup, extra latency from network hardware, processing time on the server, and also excludes time for actually transferring the data. Bandwith only matters for that last part.
For this reason, trying to do as few requests to as few domains as possible is still good advice if you want fast load times for your website (this is also part of the reason why ad networks slow down a page). HTTP/1.1 improves this since multiple requests can be sent to a webserver without having to wait for previous requests to complete (though most browsers deactivate HTTP pipelining). HTTP/2 even allows a server to send a response before it received a request, which avoids extra latency for the request. However, all of that helps only when connecting to a single server that is also sufficiently smart to perform these optimizations – not necessarily the case for a REST API.
When a couple of microservices are used internally, latency is not a major factor: you'll probably run all your services in a single data center, not on different continents. But when exposing a REST API, it's probably better to only have a single API. That way, it doesn't matter if it's implemented with microservices internally.
When designing your public API, you can structure it in a way that reduces the need for extra requests. E.g. for a question and answer site, you might want to retrieve a list of recent questions. This could be done very “cleanly” by returning a list of question IDs:
GET /recent-questions HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-type: application/json
["1234", "1235", "1236", "1237"]
But how will that be used? If I want to render a list of questions, I'll need the title, score, date, usernames, etc.. I would have to make an extra request for each of these. But if we instead anticipate these requirements and include them in the response, extra load times can be avoided:
GET /recent-questions?format=short HTTP/1.1
HTTP/1.1 200 OK
Content-type: application/json
[{"id": "1234", "score": 2, "title": "How can I frob a bar?", ...}
,...
]
Many frameworks for client-side rendering (e.g. React) see this problem and allow the first response to be rendered on the server. The client then receives the full HTML document immediately without having to make extra requests. Similarly, you should try to implement “server-side rendering” for your REST APIs.
In implementing Micro-services it is usually the whole idea to have small, single task, services as this has a lot of benefits for simplicity and maintainability, etc. these days a lot of people have enough bandwidth that the increased number of requests & responses has little impact on the responsiveness of the site(s).
However, sometimes you find that there is a negative impact, such of when a large number of the clients for the services that you provide are in areas with low bandwidth. In these cases it might be worth considering implementing an dispatch & aggregation service that receives the initial request, dispatches it to the various micro-services, collates the responses and sends the collated reply, possibly with a mechanism where, if some services are taking a long time, partial responses can be sent and then followups posted.
