JSByte: 10 myths about GraphQL

What is(n't) GraphQL - the misconceptions.
With GraphQL, you get exactly what you asked for. It is great for getting multiple resources in one request. In this issue of JSByte, I will address some common misconceptions about GraphQL.
Myth 1: GraphQL only works with graph like structures.
Reality: GraphQL can be used to query a graph database, but it is not it's only use case. The "graph" in GraphQL is used to represent the graph-like structure of data.
Myth 2: GraphQL only works with databases or data sources that are graph based.
Reality: 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 3: Data fetching with resolvers, queries and mutations work magically.
Reality: 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.
Myth 4: GraphQL is a database language like SQL.
Reality: GraphQL is a programming language - specifically a query language for API. GraphQL's spec defines how GraphQL runtimes should implement the language and how data should be communicated between client and server. There are databases such as DGraph that implement the GraphQL spec, allowing clients to use GraphQL to query the database.
Myth 5: GraphQL replaces Redux or any state management library
Reality: Redux is 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.
Myth 6: You can't have REST endpoints in your implementation with GraphQL.
Reality: You can plug in multiple REST endpoints or even multiple GraphQL endpoints in your application.
Myth 7: GraphQL is good only for front-end developers.
Reality: 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 8: GraphQL will write database queries itself, I just need to specify schemas and the relation between them.
Reality: 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.
Myth 9: GraphQL is used to draw graphs.
Reality: Often people new to GraphQL think that it is a graph plotting software such as D3. GraphQL doesn't plot graphs.
Myth 10: It requires complicated clients and is near impossible to do with a simple HTTP fetch
Reality: 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.
Read the full article here.
TL;DR
Myth: GraphQL only works with graph like structures.
Myth: GraphQL only works with databases or data sources that are graph based.
Myth: Data fetching with resolvers, queries and mutations work magically.
Myth: GraphQL is a database language like SQL.
Myth: GraphQL replaces Redux or any state management library
Myth: You can't have REST endpoints in your implementation with GraphQL.
Myth: GraphQL is good only for front-end developers.
Myth: GraphQL will write database queries itself, I just need to specify schemas and the relation between them.
Myth: GraphQL is used to draw graphs.
Myth: It requires complicated clients and is near impossible to do with a simple HTTP fetch
---
#DEVJOKEA guy ordered a pizza with cheese, olives, onion and red pepper. On getting it, the guy shouted - It is not baked.
Delivery guy - You only get what you ask for.
--
Shruti Kapoor