To follow this chapter and run the mock backend example, you will need the following:

• Node.js with a version higher than 18
• GraphQL Demeter: https://github.com/graphql-editor/graphql-demeter
• VS Code, GraphQL Editor, Sublime Text, or any text editor to edit GraphQL files to play with the mock backend

A GitHub repository has been created for this book, and you can find the code for this chapter here: https://github.com/PacktPublishing/GraphQL-Best-Practices/tree/main/chapter-01.

Why does GraphQL bring about such significant changes? This is primarily because of introspection. In practice, this means that frontend developers, mobile developers, or any API consumers can send a query to the backend asking about the available resolvers, their parameters, and what will be returned from the backend. Thanks to this mechanism, developers can efficiently communicate with the API without diving into the system documentation.

Introspection is a mechanism that allows developers to see the entire structure of a system. Through introspection, we can not only discover what queries we can execute against the backend but also distinguish between queries for data retrieval and mutations for making changes to the system. Additionally, we receive detailed information about the returned types.

Why wasn’t this concept invented earlier, considering it is so simple and obvious? Well, it has been invented before, for...

I often reminisce about the days without GraphQL with an ironic smile on my face. I remember how, as a frontend developer, I had to call backend developers and ask why a certain field suddenly disappeared or what the name of an endpoint was because I couldn’t remember it anymore. Of course, even in REST, there are specification systems that allow for a detailed description of our backend; however, they don’t enforce it on the backend developer – they only enable it.

I was already interested in the concept of a single source of truth even before GraphQL, but as soon as I understood the power of GraphQL, I immediately decided to teach it to everyone in our company and turn it into a competitive advantage.

Understanding the source of truth

Let’s imagine a scenario where we’re starting a project from scratch without any existing systems in place. Typically, the process involves creating wireframes and...

As you can see from our library schema, even though it doesn’t have documentation, just by looking at it, we know exactly what the system based on this schema is used for. This is clear to every member of the team.

Now, let’s go further, looking at self-documenting schemas – these are GraphQL schemas that contain comprehensive and descriptive naming and connections between nodes, allowing developers to easily understand and interact with the available data and operations. Here, we will look at the different elements that make up these schemas.

Custom scalars

Scalars represent simple primitives in GraphQL. There are five built-in scalars in GraphQL: String, Int, Float, ID, and Boolean. Out of these five scalars, only ID needs to be translated, as it is used to indicate a unique key and can be either a string, a number, or a custom object.

With custom scalars, the situation is different as they behave according to how...

As I mentioned earlier, introspection is vital, and now I present to you the most important part that benefits from introspection: the GraphQL query language. While REST APIs allow for exposing the JSON schema, which provides information about the API structure, I have rarely encountered good use cases for it throughout my professional career. On the other hand, the GraphQL query language is widely used in a proper manner because the language makes it hard to make mistakes.

When I first started using GraphQL, I had this feeling of “Why didn’t people agree on such a standard earlier?” We didn’t need artificial intelligence or quantum computers for it – all we needed was to communicate and reach a consensus – but now GraphQL is commonly used and it is a standard we needed. While it may not be visibly apparent at this moment, I can confidently say that GraphQL is pushing programming technologies forward...

Mocks refers to data that is used when we don’t have the system implementation yet. Their purpose is to closely resemble the data that will be returned from a functioning backend.

But how do mocks work? It’s quite simple. Each type, except for custom scalars, ultimately resolves to basic scalars such as String, ID, Float, Int, and Boolean. By knowing the final type and the resolver path, sometimes, even with detailed documentation, we can return very accurate mock values.

Let’s take a look at our simplified Book type:

type Book {
  id: ID!
  title: String!
  author: String!
}
type Query{
  books: [Book!]!
}

If the fields are built-in scalars, we are able to provide mocks just after looking at the type. In the following JSON code, we provide a response for Query.books:

[
  {
    "id": "123abc",
    "title&quot...

In this chapter, we have reviewed the basics of GraphQL and highlighted its greatest strengths. We have learned how to query the GraphQL backend for its structure and how it is defined in the SDL. These are all solid foundations of GraphQL that will allow us to smoothly progress through this book. If you don’t understand something in the upcoming chapters, you can always come back here.

Before we dive into the heavyweight schema definition in GraphQL, I’d like us to take a look at how GraphQL relates to large language models and how these two technologies can work together seamlessly. In the next chapter, you will learn how to make GraphQL schemas AI-friendly.