GraphQL Questions and Answers

I received a list of questions from someone recently and here are the cursory responses I delivered. I'll be adding to the workflow part in the coming days. Maybe this exchange will be helpful to others starting their journey with building GraphQL clients. Answering questions that other people have is a great way for me to learn, so do ask questions. When you ask questions, it helps us both.

• Common use cases for a GraphQL implementation.

  • Bandwidth limited like mobile applications, smartwatches and IoT
  • Abstraction reduces complexity. No matter how many databases, legacy systems, and third-party APIs you use, GraphQL enables you to efficiently work across these complex and composite systems.
  • GraphQL is sometimes used to wrap an API that lacks documentation and no one on the team is sure how it works.
  • GraphQL brings several benefits, such as effective request routing, parallel request execution, and graceful failure handling when you have a growing number of microservices in your environment.
  • Decoupling the frontend from the backend. When it comes to prototyping new apps, developers need speed. GraphQL has several features that can help accelerate development so that your frontend teams can get going without depending on your backend teams.

• Common workflows followed by GraphQL APIs.

  • Step 1: Evaluation and Research
  • Step 2: Get a boilerplate stack ready
  • Step 3: Putting together the data graph and documentation
  • Step 4: Deploying it all as per the need
  • Step 5: Mocking and Testing Client Consumption
  • Step 6: Getting the resolvers and backend setup
  • Step 7: Optimizing the data path: This is where you set up things like batching and also solve N+1 problems a dataloader,
  • Step 8: Controlling and Securing the data path
  • Step 9: Testing
  • Step 10: Automating or Scripting the repeatable parts

• How does the subscription model work?

  • A subscription is basically a listener on the client side. If any data are updated, deleted or changed in any way, the server will push out the change to all clients that are subscribed to that server typically over a websocket.

• Problems faced while debugging GraphQL services.

  • Contrary to REST, GraphQL does not use Status Code to differentiate a successful result from an exception. In REST, one can send a response with an appropriate status code to inform the caller about the kind of exception encountered, e.g.:

      400: bad request (e.g. invalid inputs)
      401 or 403: unauthorized (need authentication) or forbidden (insufficient permission)
      404: resource not found
      500: internal server error
    

  • In GraphQL, we manage errors in a different way. Error handling in GraphQL is part of the schema. For example:

      type User {
        id: ID!
        name: String
      }
      type Suspended {
        reason: String
      }
      type IsBlocked {
        message: String
        blockedByUser: User
      }
      type UnavailableInCountry {
        countryCode: Int
        message: String
      }
    

  This allows us to create a union type like this:

        # "User, or reason we can't get one normally"
        union UserResult = User | IsBlocked | Suspended
  

• How do you envision the Postman GraphQL client to be?

  • It should support introspection of a graphql endpoint
  • It should support scripting in multiple languages: Java and Typescript are important
  • It should support advanced features like query caching, subscriptions and deduplication
  • Built-in pagination support