Yep. Imagine an api scheme that matches the underlying normalized database structures. In order to render a view, you may need dozens of calls to different services to gather all of the data you need. Some places have been moving towards backend for front end (BFF) as a way of providing a better abstraction layer for UI development and some have been exploring GraphQL where the data can be combined and aggregated within call as dictated by the front end. I will say that the time I’ve spent working on front ends with a good graphql implementation were much more efficient and reduced overhead of dealing with more typical API interfaces.

This isn’t something I’d rush into though. There is real overhead in managing graphql and in my opinion is best suited for extremely large API spaces that most companies simply don’t have to deal with. Microsoft and their graphql implementation is one where I see it as a better option than hundreds if not thousands of different services with different endpoints.

https://developer.microsoft.com/en-us/graph/graph-explorer

I’ve done better with less:

https://danangell.com/blog/posts/type-level-api-client/