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)
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?
Could it be dataloader?
github.com/graphql/dataloader
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.
Short, concise, and perfect 👌👍
Thanks for sharing! Really helpful for interviewees.