Is GraphQL a Database Technology?
Is GraphQL only for React / Javascript Developers?
How to do Authentication and Authorization?
Does GraphQL Support Offline Usage?
How to do Server-side Caching?
List the key concepts of the GraphQL query language
Explain the main difference between REST and GraphQL
What kind of operations could GraphQL schema have?
Are there any disadvantages to GraphQL?
GraphQL is a query language created by Facebook in 2012 which provides a common interface between the client and the server for data fetching and manipulations.
The client asks for various data from the GraphQL server via queries. The response format is described in the query and defined by the client instead of the server: they are called client‐specified queries.
The structure of the data is not hardcoded as in traditional REST APIs - this makes retrieving data from the server more efficient for the client.
No. GraphQL is often confused with being a database technology. This is a misconception, GraphQL is a query language for APIs - not databases. In that sense it’s database agnostic and can be used with any kind of database or even no database at all.
No. GraphQL is an API technology so it can be used in any context where an API is required.
On the backend, a GraphQL server can be implemented in any programming language that can be used to build a web server. Next to Javascript, there are popular reference implementations for Ruby, Python, Scala, Java, Clojure, Go and .NET.
Since a GraphQL API is usually operated over HTTP, any client that can speak HTTP is able to query data from a GraphQL server.
Note: GraphQL is actually transport layer agnostic, so you could choose other protocols than HTTP to implement your server.
A successful GraphQL query is supposed to return a JSON object with a root field called "data". If the request fails or partially fails (e.g. because the user requesting the data doesn’t have the right access permissions), a second root field called "errors" is added to the response:
{
"data": { ... },
"errors": [ ... ]
}GraphQL helps where your client needs a flexible response format to avoid extra queries and/or massive data transformation with the overhead of keeping them in sync.
Using a GraphQL server makes it very easy for a client side developer to change the response format without any change on the backend.
With GraphQL, you can describe the required data in a more natural way. It can speed up development, because in application structures like top-down rendering in React, the required data is more similar to your component structure.
Every GraphQL server has two core parts that determine how it works: a schema and resolve functions.
The schema is a model of the data that can be fetched through the GraphQL server. It defines what queries clients are allowed to make, what types of data can be fetched from the server, and what the relationships between these types are.
Consider:
type Author {
id: Int
name: String
posts: [Post]
}
type Post {
id: Int
title: String
text: String
author: Author
}
type Query {
getAuthor(id: Int): Author
getPostsByTitle(titleContains: String): [Post]
}
schema {
query: Query
}Authentication and authorization are often confused. Authentication describes the process of claiming an identity. That’s what you do when you log in to a service with a username and password, you authenticate yourself. Authorization on the other hand describes permission rules that specify the access rights of individual users and user groups to certain parts of the system.
Authentication in GraphQL can be implemented with common patterns such as OAuth.
To implement authorization, it is recommended to delegate any data access logic to the business logic layer and not handle it directly in the GraphQL implementation.
GraphQL is a query language for (web) APIs, and in that sense by definition only works online. However, offline support on the client-side is a valid concern. The caching abilities of Relay and Apollo might already be enough for some use cases, but there isn’t a popular solution for actually persisting stored data yet.
One common concern with GraphQL, especially when comparing it to REST, are the difficulties to maintain server-side cache. With REST, it’s easy to cache the data for each endpoint, since it’s sure that the structure of the data will not change.
With GraphQL on the other hand, it’s not clear what a client will request next, so putting a caching layer right behind the API doesn’t make a lot of sense.
Server-side caching still is a challenge with GraphQL.
Key concepts of the GraphQL query language are:
- Hierarchical
- Product‐centric
- Strong‐typing
- Client‐specified queries
- Introspective
The main and most important difference between REST and GraphQL is that GraphQL is not dealing with dedicated resources, instead everything is regarded as a graph and therefore is connected and can be queried to app exact needs.
There are three kinds of operation available at the entry points to the schema:
- Schema must have
queryobject type whose fields are the set of query endpoints of the server application. - A schema may optionally have
mutationobject type, whose fields are the set of mutations available on the server. - The schema may have a
subscriptionobject type, whose fields are the set of subscriptions.
Disadvantages:
- You need to learn how to set up GraphQL. The ecosystem is still rapidly evolving so you have to keep up.
- You need to send the queries from the client, you can just send strings but if you want more comfort and caching you'll use a client library -> extra code in your client
- You need to define the schema beforehand => extra work before you get results
- You need to have a graphql endpoint on your server => new libraries that you don't know yet
- Graphql queries are more bytes than simply going to a REST endpoint
- The server needs to do more processing to parse the query and verify the parameters