7 ms·
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 cont
by schickling 8y ago
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 8y agoFor 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 8y agoI 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 8y agoSure, I was only listing the ones from my toolbox. :)
- e12e 8y agoI'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)] .