[schickling]

This is a fantastic point!

Co-creator of How to GraphQL here. I’m very excited to tell you that we’re currently working on a new iteration of the page and content that will include more in-depth chapters about dataloaders, authentication, authorization and other advanced topics.

Would be great to hear more thoughts on which topics you’d like to see covered.

[pjmlp]

For me to even start thinking about GraphQL instead of REST, there needs to exist Java, .NET and C++ mature libraries for GraphQL at the same level of available REST ones.

Using JavaScript ones is not an option. So that is the kind of thing I would care about.

[monch1962]

I would add Python and Go to that set of required, mature server-side libraries.

If there's solid libraries for each of the common languages used to write serverless code, then I think that'd be a big plus for decision makers who are on the fence about adopting GraphQL

[pjmlp]

Sure, I was only listing the ones from my toolbox. :)

[e12e]

I've yet to go beyond a cursory skim of graphql - but my first impression is that in the end you get to write your very own query planner/optimizer - with the "benefit" of optimizing across wildly different data stores like unifying a few different sql databases, a few filsystem graph/hierarchies of meta-data and a handful of semi-structured document stores in the form of json/soap services... So a lot harder than the already pretty hard problem of writing a query planner for "just" an rdms.

But I think there's something "there" - graph dbs, datomic, web prolog - they all seem to point to clients asking a "what" with the server figuring out the "how" [ed: and not in the least: whence (from where)] .