This article was originally published on mtso.io as GraphQL as a Database Query Language.
The GraphQL ecosystem has quickly grown with development tools, client-side framework integrations, reflection-based generators, and backend frameworks. Thus far, the most unexplored area is GraphQL as the native data query language that is interpreted on the database server itself. Taking cues from projects like dgraph (GraphQL over RocksDB), PostGraphile (generated GraphQL endpoint based on PostgreSQL schema), and tuql (generated GraphQL endpoint based on an SQLite database), I propose the development of a new datastore that uses GraphQL as a fully native query language. Key advantages of having a database that understands GraphQL queries are expressive metadata queries, optimized storage, and reduced overhead.
GraphQL can enrich system metadata queries with relevant information. Imagine using GraphQL to query system catalogs, user info, or runtime statistics. For example, a query on running databases could be populated with each user's names, permission levels, and timestamp of the latest query without table joins that increased the number of results.
At the same time, a GraphQL language layer driving the execution planner has the opportunity to optimize the storage of data. Placing the GraphQL interpreter closer to the storage engine lets the database server make better decisions than the application client about how to store the data. Similar to how column-oriented databases store column values next to each other as opposed to placing full rows side-by-side like row-based databases, a GraphQL-oriented database could group the values of a type together. The indices could even be inferred from the schema based on the arguments specified in the schema's mutations.
With the language layer running on the database server itself, there would be less tooling to manage at deployment time. Instead of a GraphQL app server fronting a database server, a GraphQL database can replace two processes with one and avoid the additional point of failure. Furthermore, all GraphQL queries would be invoked directly on the database server, saving network round-trips for complex queries.
A proof-of-concept implementation of these features could be a PostgreSQL extension that added a GraphQL interpreter. This would save some work by using an existing storage engine. Further optimizations to the storage layer could be developed later after this strategy proves useful.
In order to reduce the friction of managing such a database, system operations should be exposed as GraphQL mutations. This could be manifested in a default "system" GraphQL schema like system catalogs and tables in other databases. Types could replace table or collection definitions, mutations could replace system commands, and subscriptions could replace triggers.
Ultimately, such a database will make data querying and manipulation more powerful by expressing nested relationships with the natural GraphQL syntax. With GraphQL as the only language on the database side, fewer context switches need to be made during development.
Update: Prisma from graph.cool is an active project in this space.
Top comments (3)
Wow, this sounds a lot like what we're working on with Prisma!
The idea is to automatically generate a GraphQL layer for any kind of database. Building the actual GraphQL server then becomes easy thanks to tools like graphql-yoga and GraphQL bindings!
To get a glimpse of what this looks like, check out the 4min introductory video or get started with a GraphQL boilerplate project.
I knew I had missed a project from you guys at graph.cool! When I was listing the prior arts, I thought I had heard something in this direction from graph.cool, but just couldn't remember the name.
GraphQL is such a good idea that you just get the feeling that some of this is inevitable and it's just a matter of getting the details write over time.
I'd love for more posts and conversations around GraphQL on dev.to and if it can help drive attention to interesting projects, all the better!