Let’s start with the idea of a database, and a basic query. Server taps the database. Server brings back persistent state information that allows an application to update, and maybe a GUI. What’s wrong with this picture? Not much at first, of course. A GET request is the anchor of RESTful architecture, and in some ways the anchor of the web. So basic that fetch syntax defaults to that type.
But, of course, there is more to HTTP requests than GET. There is POST. There is PUT. There is DELETE, and more arcane methods besides. And sometimes, even within the confines of the GET, the sort of information the frontend really needs does not line up with the easiest way to query the database.
Imagine a series of user profiles. You need name and age (for some reason). You do not want address. You do not want email. You do not want fingerprint data. (This is a strange database.)
The easiest way to query your database with RESTful architecture might be to pull all information related to your user of interest, by ID, and then leave it up to the frontend to clear out all of the information you don’t need. The user sees what the user needs to see, but the poor server has overqueried.
The GraphQL query language can fix this overfetching problem, by allowing for unnecessary information to be ignored much earlier. There are other things GraphQL is good at, including bundling requests into a single API call, and in streamlining type checking.
But the purpose of GraphQL, the core idea, is that it is possible for servers to be more dynamic in asking a server for information. Is this the future? Who knows?
GraphQL started at Facebook, and has spread to replace RESTful database calls at companies like The New York Times, Twitter, and GitHub. That seems like a sign GraphQL will stick around at least for a few more years.
Like any new technology, an ecosystem of support tools is developing around GraphQL. The GraphiQL user interface allows for quick browser queries to check a database, providing a space for input on the left, and output on the right.
My project team has thrown its hat in the ring with a technology that may fit the needs of some subset of users: GraphQuill. GraphQuill takes the idea of GraphiQL and brings it into the VS Code environment. With the GraphQuill extension, users can write queries to their API directly from a VS Code project file, and have output from those queries be directed to a VS Code channel immediately.
GraphQuill is a young, incremental product, that solves a specific problem for a specific subset of GraphQL users, just like GraphQL itself solves a set of specific problems for software engineers. We’re proud to know the way we exist in context.
If you’re interested in knowing more about the way we contribute to the ecosystem, please click the links below, to read a more technical piece about our product, to visit our extension on the VS Code Marketplace, or to go directly to the documentation.