Usually it's forced on the backend by the frontend team.
Really, it's just more awkward than writing a straight-ahead REST implementation.
Also the error-handling semantics gets pushed to the backend, and the frontend team (who generally doesn't like handling errors) doesn't really know what to do with errors in general...so the UI design team needs to add that sort of error handling to the UI which makes everyone confused because usually there's nothing you can do about errors on the client side.
The error handling issue can be seen with this simple example: you federate 10 API calls, and 9 of them work fine. Do you return partial data? How do you indicate to the front end that there's partial data? What if the data in the 10th call is the one they need in the UI?
This implies that you need yet another state indicator that says "part of the data was returned" (if the destination was a field)...which is different than "that field was empty." And that's at a minimum.
mannyv|2 years ago
Really, it's just more awkward than writing a straight-ahead REST implementation.
Also the error-handling semantics gets pushed to the backend, and the frontend team (who generally doesn't like handling errors) doesn't really know what to do with errors in general...so the UI design team needs to add that sort of error handling to the UI which makes everyone confused because usually there's nothing you can do about errors on the client side.
The error handling issue can be seen with this simple example: you federate 10 API calls, and 9 of them work fine. Do you return partial data? How do you indicate to the front end that there's partial data? What if the data in the 10th call is the one they need in the UI?
This implies that you need yet another state indicator that says "part of the data was returned" (if the destination was a field)...which is different than "that field was empty." And that's at a minimum.