2 ms·

I wrote about GraphQL on here before [1]. I don't share the author's enthusiasm that it's "awesome" that "the schema is all backed by arbitrary code" -- I think

by niftich 10y ago

I wrote about GraphQL on here before [1]. I don't share the author's enthusiasm that it's "awesome" that "the schema is all backed by arbitrary code" -- I think this is a bad trade-off, because you still have to have some custom data-munging layer between your GraphQL acceptor and your backend datasources, just like you had to do to, but with different code, to implement a REST service. However, once canned ORMs or datastores that natively understand GraphQL (like dgraph) become available, the ecosystem will definitely enable rapid integration -- provided we keep in mind the lessons learned about user-supplied queries from the early SQL-on-the-web days. [1] https://hn.algolia.com/?query=niftich%20graphql&sort=byDate&type=comment https://hn.algolia.com/?query=niftich%20graphql&sort=byDate&...

segphault 10y ago
>I don't share the author's enthusiasm that it's "awesome" that "the schema is all backed by arbitrary code" -- I think this is a bad trade-off Yup, and it also forces you to sacrifice programming language portability. Kind of important in a microservice scenario where you might want to have multiple distinct services written in different languages that support the same set of GraphQL types. People don't seem to realize that there is a whole separate dedicated schema language for GraphQL that will eventually replace the mediocre embedded DSLs. The only reason the current implementations all use the embedded DSLs is because implementing a parser for the custom schema language is non-trivial. There are a lot of things that I really like about GraphQL, but I think it would have been saner if they had aimed for a way to express the schemas and queries in something like JSON that everybody already speaks.