DEV Community

Alex 👨🏼‍💻FullStack.Cafe
Alex 👨🏼‍💻FullStack.Cafe

Posted on • Updated on • Originally published at fullstack.cafe

5 GraphQL Interview Questions and Answers You Should Know

5 GraphQL Interview Questions You Should Know
GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

Originally published on FullStack.Cafe - Never Fail Your Tech Interview Again

Q1: What is GraphQL?

Topic: GraphQL
Difficulty: ⭐⭐

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.

🔗Source: howtographql.com

Q2: List the key concepts of the GraphQL query language

Topic: GraphQL
Difficulty: ⭐⭐⭐

Key concepts of the GraphQL query language are:

  • Hierarchical
  • Product‐centric
  • Strong‐typing
  • Client‐specified queries
  • Introspective

🔗Source: blog.risingstack.com

Q3: Explain the main difference between REST and GraphQL

Topic: GraphQL
Difficulty: ⭐⭐⭐

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.

🔗Source: medium.com/codingthesmartway-com-blog

Q4: How to do Server-side Caching?

Topic: GraphQL
Difficulty: ⭐⭐⭐

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.

🔗Source: howtographql.com

Q5: Are there any disadvantages to GraphQL?

Topic: GraphQL
Difficulty: ⭐⭐⭐⭐

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

🔗Source: stackoverflow.com

Thanks 🙌 for reading and good luck on your interview!
Check more FullStack Interview Questions & Answers on 👉 www.fullstack.cafe

Top comments (5)

Collapse
 
bgadrian profile image
Adrian B.G.

Nice.

When I first read about GraphQL, when FB made it open source, I remember they had a cache solution, that kept all the records, and it had a push-update cache mechanism, meaning when the servers mutated the data it updated the GraphQL cache too.

I presumed it was in all implementations, what happened to that?

Collapse
 
omerg profile image
Omer Gurarslan

Could it be dataloader?

github.com/graphql/dataloader

Collapse
 
samarpanda profile image
Samar Panda • Edited

Server side caching for GraphQL: How about caching it behind resolvers? Again it depends on us whether we need to club multiple resolver to cache it with one key or multiple. So, i don't think caching is an issue when it is related to server-side.

Yes, i agree that REST is more intuitive to handle. As this is what we have been handling pretty long time now. In case of GraphQL it has a different way.

Collapse
 
whoisryosuke profile image
Ryosuke

Short, concise, and perfect 👌👍

Collapse
 
liuderchi profile image
TC Liu

Thanks for sharing! Really helpful for interviewees.