I love talking about GraphQL, especially with people who have been working with GraphQL or thinking of adopting GraphQL. One common question people have is why would someone want to move to GraphQL from REST. There are a ton of resources that talk about the difference between REST and GraphQL and those are great to check out if you are interested in how those two are different. In this blog post, I want to answer some common misconceptions and questions asked about GraphQL.
How do you benefit from GraphQL on the front end?
As a Front End Engineer, I like working with a GraphQL API for the following reasons:
- Instantly test queries and mutations using GraphiQL or playground
- Less data means lighter state management
- Offload heavy lifting to the server through resolvers
- Documentation that is up-to-date and interactive
How is it better than REST?
- One endpoint to fetch all resources.
- Avoid over fetching of data (getting too many fields when only a few fields are needed).
- Avoid under fetching of data (having to call multiple APIs because one API doesn't give back all the information needed).
Myth: GraphQL only works with graph like structures.
GraphQL can be used to query a graph database, but it is not its only use case. The "graph" in GraphQL is used to represent the graph-like structure of data. You model the data in terms of nodes and how they connect to each other. Schema is used to represent this modelling.
There is no limitation in the GraphQL spec that enforces that the data source should be a graph.
Myth: GraphQL only works with databases or data sources that are graph based.
It's a misconception that you need to rewrite your database to adopt GraphQL. GraphQL can be a wrapper around any data source, including databases. GraphQL is a query language for your API - which means it is a syntax of how to ask for data.
Myth: Data fetching with resolvers, queries and mutations work magically.
You will need to define exactly what each of them needs to do. You will be writing functions that get called when queries are fired, writing functions for resolvers that send back exactly the data you need and knows which API to call. You will be defining what data returns through those functions by calling resolvers.
Myth: GraphQL is a database language like SQL.
GraphQL is a programming language - specifically a query language. GraphQL's spec defines how GraphQL runtimes should implement the language and how data should be communicated between client and server. GraphQL is used to ask for data and can be used in multiple places in any layer from front end to back-end. There are databases such as DGraph that implement the GraphQL spec, allowing clients to use GraphQL to query the database.
Myth: GraphQL replaces Redux or any state management library
Redux is a state management library. GraphQL is not a state management library. GraphQL helps to get less data, which in turn leads to less data to manage on the client-side, but it is not a state management solution. You will still need to manage state - albeit lightweight. Client libraries like Apollo and Relay can be used to manage state and have caching built-in. GraphQL is not a replacement for Redux - it helps to reduce the need for it.
Myth: You can't have REST endpoints in your implementation with GraphQL.
You can plug in multiple REST endpoints or even multiple GraphQL endpoints in your application. Although it is not a best practice to have multiple REST endpoints, it is technically possible.
Myth: GraphQL is difficult to introduce in an existing project.
GraphQL can be plugged into an existing project. You can start with one component of business logic, plug in a GraphQL endpoint, and start fetching data through GraphQL. You don't need to scrap an entire project to start using GraphQL. If switching to GraphQL endpoint is still a daunting task, you can start by masking a REST endpoint into a GraphQL endpoint using resolvers.
Myth: GraphQL is only for front-end developers.
GraphQL is platform agnostic. In my opinion, the beauty of GraphQL's benefits comes from the inside out - backend to frontend. As a backend developer, you are able to expand the API by adding fields without having to publish a new version of the API. You don't need to write different endpoints for different needs since clients can fetch whatever data they need. With GraphQL, you have visibility of what fields clients are using, giving powerful instrumentation.
Myth: GraphQL will write database queries itself, I just need to specify schemas and the relation between them.
You may need to write the database queries depending on which GraphQL library you are using. However, some libraries like Neo4j and Prisma write database queries too and abstract the logic away from the developer. Everything including resolvers, queries, mutations needs to be defined.
Myth: GraphQL is used to draw graphs.
Often people new to GraphQL think that it is a graph plotting software such as D3. GraphQL doesn't plot graphs.
Myth: It requires complicated clients and is near impossible to do with a simple HTTP fetch
GraphQL API itself is really simple to call. You don't need clients to call a GraphQL API. You can call GraphQL API with a simple curl command over HTTP. Check out this article to learn how.
Myth: It replaces ORMs.
Lately we see a lot of DB and GraphQL integration but GraphQL itself is not that.
I think GraphQL is awesome and everyone should try it out. I particularly love that I can fetch data that I need, without having to throw away the rest of the payload - because the payload I get back from a GraphQL API is the exact payload I need for my needs.
There are a multitude of libraries that can help you get started with GraphQL. To get started with GraphQL, start with the documentation or check out this Udemy course that I found helpful when I was new to GraphQL.
If you liked this article, check out my Twitter where I post GraphQL things and DevJokes.
Liquid error: internal
Latest comments (10)
Hello friends.
I'm going to implement a Graphql API with NodeJS (for GraphQL server will use graphql-yoga or appolo), but my Database it will be MSSQL, could you suggest my any ORM, because Prisma support only Postgre and MySQL. I've seen Knex which support most of the DB's but is there any better than it?\
Kind Regards
I don't see how using one endpoint for all your requests is a plus. Of course it's more convenient for the frontend Dev because they don't have to remember all the endpoints but this convenience comes with performance issues like:
Another benefit of graphql is having to perform a single server call, with REST you probably would make a lot of calls to the different endpoints.
It's costs way more to make a request to a server far away (tens of ms) than to parse a request (< 1 ms)
Hi, I'm used Hasura GraphQL API that wraps Postgres database, it's good example of how you can use GraphQL with SQL database, easy to use, ready for work in a short time
I’m confused with graphQL.... can u use it as a database... or does it filter database queries?
I am self taught...
It's an API specification which means in an interface that goes between a data source and a client to allow you and other developers to access it. It has a singular endpoint(url) that you send requests to, using GraphQL specific syntax. The GraphQL spec defines how that endpoint should interpret your request and ultimately resolve it(return data, or accomplish the requested task). Query requests will return information and Mutation requests will typically either change/create/update/delete information.
The other great benefit is that if you have multiple varying data sources you can use GraphQL to easily unify them under a singular endpoint. You just have to write the resolvers and connect them to the correct data sources.
Hi mate.
Ask yourself, can you use HTML as a database?
Answer is no. Simply because it's a programming language.
Typically, a website or an app would send a GraphQL query to the server. The sever would see your query and would read the requested data from its database. And would return the data back to the website/app.
Html is not a programming language though
Great post, thank you for sharing. I'm a little confused about the myth "GraphQL is a database language like SQL." SQL is also a programming language, and more specifically a query language that is defined by a spec with many implementations of it. Is the distinction for this myth that GraphQL can be used on the frontend?
Thanks for sharing! Hopefully this clarifies some misconceptions about GraphQL for those debating adoption.