If you needed this level of flexibility in your mobile apps, why not just download the datastore to the client and use something like SQLLite, or a JSON query language on the client (similar to mongo, there are lots of options).
In addition, in reading the thing that "pushed you over the edge" ... I really don't see how REST has failed you here, in terms of how you are partitioning your data. I can't imagine that some kind of intelligent caching of data (no need to re-download playlist data to the client that hasn't changed, etc). wouldn't have been a more straightforward approach here.
I find the GraphQL stuff interesting but your problems would have been better served by refactoring what you had rather than moving to a completely new API and query format, at the cost of sacrificing an easy to use interface for your internal and (maybe) external consumers of your API. I'm not convinced you won't have the same issues with GraphQL and could stand a bit more pragmatism.
This is exactly what I thought too. From what the author described, it seems that they were just using REST incorrectly. When a view wants tags from a playlist, the solution is not to include tags in every other request. You can simply include a query parameter instead:
GET /playlists/ID?tags=true
This lets the server knows to include the extra information for that request, keeping your original endpoint clean.
We don't know all the details, but from what the author wrote, it seems they were shortsighted to switch to a shiny new tech instead of looking for better ways to refactor what they currently had.
In addition, in reading the thing that "pushed you over the edge" ... I really don't see how REST has failed you here, in terms of how you are partitioning your data. I can't imagine that some kind of intelligent caching of data (no need to re-download playlist data to the client that hasn't changed, etc). wouldn't have been a more straightforward approach here.
I find the GraphQL stuff interesting but your problems would have been better served by refactoring what you had rather than moving to a completely new API and query format, at the cost of sacrificing an easy to use interface for your internal and (maybe) external consumers of your API. I'm not convinced you won't have the same issues with GraphQL and could stand a bit more pragmatism.