API / GraphQL Interview Questions

GraphQL is a new API standard designed and developed by Facebook. It is an open-source server-side technology that is now maintained by a large community of companies and individuals worldwide. It is also an execution engine that works as a data query language and used to fetch declarative data.

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.

No. GraphQL is not a Database Technology. GraphQL is data query and manipulation language for APIs - not databases.

When the users fetch the data in GraphQL, it retrieves only the minimum amount of data that is required by the client. Even if the object model contains a lot of fields, the client can request only the required fields.

REST is not so flexible to cope up with the rapidly changing requirements of the clients. When the data gets more complex, the routes get longer. Often, it is challenging to fetch the data with a single request. That's why Facebook takes a step to develop a new API technology named GraphQL to cope up with the REST's limitations.

Over-fetching is a response where the client gets extra/additional data for an API request that the client won't use. Over-fetching unnecessarily increases the payload size.

Under-fetching is a response where the client doesn't get enough data. The under-fetching response doesn't have enough data with a call to an endpoint, so you have to call a another endpoint to fulfill your request or multiple API calls to fetch the complete data.

A successful GraphQL query is supposed to return a JSON object with a root field called "data". If your request query fails or partially fails, you will see a second root field called "errors" in the response.

{  
  "data": { ... },  
  "errors": [ ... ]  
}   

In GraphQL, when a client requests a query, the server returns the JSON format response based on the query the client uses for the request.

GraphQL Simplifies API Development: Unlike REST which uses a different endpoint for each resource, a GraphQL API only needs to use one. Reducing the number of endpoints simplifies the development process. Fetching becomes easier as you do not have to make calls to many endpoints to fetch a set of data.

GraphQL uses a simple JSON-like data structure, making it easy for anyone working with JSON to interpret and use. The response format is JSON as well.

Strong Typing Provides Safety: Types validate the structure of queries submitted to the API. This ensures that the requested data is in the right format.

GraphQL Is Fast: While debatable, the performance of GraphQL appears to be faster than REST queries as GraphQL allows you to run multiple queries at a time rather than on several trips. You can also select an object or a sub-selection of fields for that object.

Efficient Data Fetching Using GraphQL: When you make a request, GraphQL queries the server and returns a response specific to your query. There is no room for over-fetching or under-fetching of data. This reduces the chances of having too much data or not enough data on the network.

Best for complex systems and microservices: GraphQL is versatile. You can integrate multiple systems behind GraphQL's API. Its simple system simplifies the complexity of other systems it integrates with. For example, if it's fetching data from an application or server, it packages it up in its simple format.

GraphQL Avoids Versioning: GraphQL does not depend on versions of your schema. In case you make changes to your database and add new fields, it does not impact existing queries. The GraphQL API will only query existing resources and hide outdated data.

Scalability: Applications handling data from many systems can easily scale their APIs using GraphQL. Scalable APIs ensure the widespread adoption and success of an application. You can also use it with any type of database whether relational or non-relational.

GraphQL Lets You Use Your Own Code: GraphQL APIs are compatible with modern programming languages such as Java, Javascript, Scala, Python etc. so you can create code in your preferred language. You can create functions in the fields that influence your application.

Powerful Developer Tools and Community Support: GraphQL has powerful developer tools that allow you to create new operations. It also has validation and auto-complete features. You can also register a management service to track changes in the schema.

Error Handling Complexity: The GraphQL queries always return a HTTP status code of 200, regardless of whether or not that query was successful. If your query is unsuccessful, your response JSON will have a top-level "errors" key with associated error messages and stacktrace. This can make it much more difficult to do error handling.

Lack of built-in caching support: It is complicated to implement a cache with GraphQL than implementing it in REST. In REST API, we access resources with URLs, so we can cache on a resource level because we have the resource URL as an identifier. However, In GraphQL, its complex because each query can be different, even though it operates on the same entity. But most of the libraries built on top of GraphQL offer an efficient caching mechanism.

Complexity: If you have a simple REST API and deal with data that is relatively consistent over time, you would better stick with your REST API.

Rate Limiting Complexity: In REST API, you can simply specify that we allow only this amount of requests in one day, but in GraphQL, it is difficult to specify because it doesn't have different endpoints/varied JSON request structure.

A schema is like a contract between the server and the client. It defines what a GraphQL API can and can't do, and how clients can request or change data. It's an abstraction layer that provides flexibility to consumers while hiding backend implementation details.

A GraphQL Schema Definition Language (SDL) is the most concise way to specify a GraphQL schema. A schema is a collection of object types that contain fields. Each field has a type of its own. A field's type can be scalar (such as an Int or a String), or it can be another object type. For example, the Book object type will have an author field of type Author.

type Book{
  id: Int
  authors: [Author]
  isbn: String!
}

 "Author of book(s)"
  type Author {
    id: ID!
    "Author's first and last name"
    name: String!
    "Author's profile picture url"
    photo: String
  }

Yes, name is a String type and ! denotes that name cannot be null.

An exclamation mark after a field's type marks it as non-nullable.

Schema Definition Language (SDL) is used for writing schemas. SDL is the language that is used to write GraphQL schemas.

GraphQL supports 3 types of operations: query, mutation, and subscription. The query is used for the request, and it is a read operation, the mutation is used for write operations, and subscription is used for listening for any data changes. The server sends a notification message to the client after any data changes, if the client is subscribed to that event.

A Mutation is a GraphQL Operation that allows you to insert new data or modify the existing data on the server-side. You can think of GraphQL Mutations as the equivalent of POST, PUT, PATCH and DELETE requests in REST.

In GraphQL, mutations are used to write or change data, while queries are used to read data. Queries are used for operations that do not have side effects, such as data retrieval, while mutations are used for operations that can modify data (CRUD operations), such as those that create, update, or delete records.

Scalar types are basic atomic data types in GraphQL that represent single values. They include types like String for text, Int for integers, Float for floating-point numbers, Boolean for true or false values, and ID for unique identifiers. Scalars are used to represent the leaves of the GraphQL query tree, serving as the foundation for more complex data structures.

In GraphQL, an exclamation point (!) indicates that a field in a query or a field argument is non-nullable. This means that the field must contain a value and cannot be empty. When used with a field, it ensures that the server always returns a value that is not null. When used with a field argument, it indicates that the client must provide the argument and it cannot be left out.

In GraphQL, each schema field corresponds to a function known as the resolver. The resolver returns the value for a given field in an operation. Resolvers provide instructions on how to compute or retrieve data from the server or other sources. They are a crucial part of implementing GraphQL servers because they translate the fields in the schema to the real data sources—which might be databases, REST APIs, or other services.