I use an API Gateway (BFF) in front of my microservices to handle the UI needs.
For example I have a microservice which calls an external service.
In the UI I don't need (NOW) all the information which the external service provides. Should my MS pass only the currently needed data to the BFF, or pass the whole response and I should "filter" the MS response in the BFF?
For Example:
The whole point of BFF pattern in the first place is to provide a purpose built interface for Frontends, and they're free to collect the data from the services that contain them. I'd suggest either:
Microservice microservice (in your diagram) manipulates the data somehow before returning them, then manipulate them as they are written (potentially by observing some event in the external system if you can) and store the processed result (potentially a local copy). If one of the above two cases will be feasible, and I very strongly suggest you avoid daisy chaining synchronous web requests, because this greatly decreases your avaiability (if each service is 95% available, the two combined are 90% available, not 95%, and this gets bad quickly). Latency is a concern (as @picolino rightly mentions), but in my experience it is much rarer for it to be a bigger concern than availability. In any case, flattening the call stack will greatly reduce the time taken to process the request anyway.
Both above options are also good from perspective of allocation of responsibilities; one service would own the customer data, and the other data doesn't need to own passing through, it can be notified asynchronously by the BFF to do any cross-cutting concerns it needs to.
If and only if none of the above are feasible, I'd suggest you consider a bit the contract of the service you're developing and the data that is needed by it before making a decision. Passing along the complete set of data blindly may or may not be a good idea, depending on what is the nature of the responsibilities of Microservice service you have there.
From single responsibility principle point of view, it's better to return just related data, more information means more than one responsibility for a method or an action.Because you are not the only user in system.It's confusing for other users when they call getUsers method,but receive information that is unrelated to users.
It comes down to how you want to utilize your External User Service.
If you think that the service gonna serve different types of requests, and better to return all info, the service should return everything. And then your BFF will filter to return only needed data.
If you want to use this External User Service for this only purpose, it should return only needed service.
In summary, you need to have a good domain design to decide how big is the service, how much data to transfer, how many other components will consume the service.
Answer to your question depends on a speed factor.
What if application must be really fast
If you need really fast service then you need to make your execution path with minimal data transfering operations inclusive BFF layer.
If external service layer have only one execution path and one API that needs you, you can just filter extra data on microservice side. This reduce amount of transfering data between MS and Frontend layer.
Or you can cache external user serivce results on MS or BFF layer to greatly increase speed of your application. If it possible and makes sense, ofcourse.
What if speed factor not so important?
Usually, increasing speed and/or performance makes you to write more code, like separate execution paths or something. If speed factor is not so important you can reduce amount of code and reuse same execution path between normal and filtered requests with filtering results on frontend side.
That makes a positive effect on your codebase. Less of code - less of problems.
