My concern is regarding the server-side implementation of the GraphQL endpoint. My understanding is that GraphQL endpoints couple tightly to a graph-oriented backend. Facebook already has TAO so it's a no-brainer, but how feasible do you think a normal SQL-based backend can adapt to efficiently process arbitrary GraphQL queries? Or would it be easier to switch to a graph-oriented database (e.g. neo4j) instead? The former option seems to be quite an engineering endeavor, while the latter is just too risky right now.
Not a Facebooker so I haven't worked with GraphQL per say (sad face), but a quick-and-dirty way to do this type of deep data fetching on an SQL database is to fetch one layer at a time: do a breadth-first search on the parsed GraphQL, and at the end of each layer you should have enough data in API-server memory to know the IDs of everything in the subsequent layer. Rails has largely switched to doing this rather than deep joins. Given that the depth is based on how many layers deep your GraphQL is, rather than the number of records, you avoid the N+1 problem without needing to switch to a graph database, and there's a relatively constant number of DB hops required. The main caveat I see is that cursor-based pagination is hard to emulate in SQL without persistent database connections... not sure if there's a scalable way to do this while keeping the GraphQL endpoint stateless.
Having experimented with neo4j a year ago, I would concur that it hasn't been battle-tested for use as a high-availability database for web apps; it was used much more for offline analytics AFAIK. Thingdom did some REALLY cool things using neo4j from JS, and their ideas for modeling news feeds were really mindblowing, but I'm hesitant to put anything mission-critical on it just yet from both a technical-debt perspective and a speed/scalability perspective.
GraphQL itself doesn't make any assumptions about the storage engine being graph-oriented or otherwise. It's true that the grammar makes it easy to express graph-like relationships (eg. using the notion of one-to-many connections), and from the perspective of the application it can request an arbitrarily complex hierarchy of nested objects, but how and where the underlying data gets fetched is implementation specific and I can imagine adapting GraphQL to any number of different data source types.
My concern is regarding the server-side implementation of the GraphQL endpoint. My understanding is that GraphQL endpoints couple tightly to a graph-oriented backend. Facebook already has TAO so it's a no-brainer, but how feasible do you think a normal SQL-based backend can adapt to efficiently process arbitrary GraphQL queries? Or would it be easier to switch to a graph-oriented database (e.g. neo4j) instead? The former option seems to be quite an engineering endeavor, while the latter is just too risky right now.