I think one of the reasons why there are so many different approaches and libraries out there is due in part to what GraphQL is. Its both more, and less, than a

I think one of the reasons why there are so many different approaches and libraries out there is due in part to what GraphQL is. Its both more, and less, than an alternative to a REST API. Its primary use case right now is to replace a REST API, but at its heart, GraphQL is a specification for a type system, query language and the semantics to resolve one against the other. I can’t speak to other implementations, but graphql-js gives you the tools to parse queries and schemes into abstract syntax trees, and once you have that, there’s a lot you can do. With those tools, people have been creating all sorts of things. Take a look at Apollo’s work on merging schemas together for a good example. [1] Personally, I’m working on a proxy layer that will sit in front of a GraphQL API and act as a sort of business rule engine. It analyses the incoming queries to figure out which sets of rules need to be run. These sorts of solutions don’t have anything to do with APIs. Heck, you could create a GraphQL schema to act as a classic data access layer, and call it internally from your own code... Which is what Prisma is doing. I think this ability to leverage the capabilities of GraphQL to create innovative new solutions muddies the waters for those who are looking to create a simple API. [1] https://www.apollographql.com/docs/graphql-tools/schema-stitching.html https://www.apollographql.com/docs/graphql-tools/schema-stit...