Had to double-check this post's date since it feels like it was from five years ago with barely anything new. But good choice, IMHO! I'm a fan of GraphQL. It s

Had to double-check this post's date since it feels like it was from five years ago with barely anything new. But good choice, IMHO! I'm a fan of GraphQL. It serves as an excellent BFF framework for performant frontends. You get types, tooling, conventions for free and if you use something like Apollo GraphQL Client, it normalizes GraphQL responses and caches the individual entities. In addition, I realized in the last 5 years how it helped managing product teams. There were teams with die hard frontend devs that practically annoyed me every day with requests for new/changed endpoints; once I got very pi*ed, implemented a GraphQL backend and gave them the GraphiQL UI such that they could discover and query the data themselves. Saved me a lot of frustration and was fun for them. You can theoretically do the same with REST but if you dogmatically stick to Entities-Resources, it will not be performant if you have lists with nested sub-fetch (e.g. a list of blogposts with their author and her name/avatar). If you start creating endpoints which return a whole ViewModel, you're IMHO starting to leave RESTland and if you're doing it right, will eventually re-create something GraphQL-ish.