>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 als

>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.