05 / 10

What are Type modifiers?

Difficulty: 5/10
Non-Null, List, Nullability contracts

when we use named types in a schema (or in query variable declarations) you can apply additional type modifiers that will affect the meaning of those values.

This allows you to:
  1. 1

    Non-Null: by adding an exclamation mark (!) after the type name.

  2. 2

    List: by wrapping the type in square brackets, [ and ].

javascript

Scenario Questions

0-2 years experience

  1. 1You need to add a new field `email` to the `User` type that must always be present. How would you define it using GraphQL type modifiers?
  2. 2If you define a field as `[String]` versus `[String]!`, what difference does the exclamation mark make for the client?
  3. 3A client is getting a null for a list field you expected to be an array. What could be wrong with your type definition?

2-5 years experience

  1. 1While implementing a mutation that accepts a list of IDs, you notice the resolver crashes when the client sends an empty array. How would you adjust the type modifiers to handle this case gracefully?
  2. 2Your team changed a field from `String` to `String!` and the frontend started seeing errors. Walk me through why that happened and how you would mitigate breaking changes.
  3. 3We have a nested type where a field returns `[Comment]!`. Explain the impact on nullability at each level and how you would debug unexpected nulls.

5-8 years experience

  1. 1Design the schema for a paginated feed where the `edges` list must never be null, but individual `node` objects can be. Which type modifiers would you use and why?
  2. 2Our GraphQL gateway aggregates services, and one downstream service returns a nullable list while another returns a non‑null list. How do you reconcile these differences in the gateway schema without breaking clients?
  3. 3Explain the performance implications of using non‑null modifiers on large list fields in a high‑traffic API.

8+ years experience

  1. 1We are planning a migration from a monolithic GraphQL server to a federated architecture. How would you approach evolving type modifiers across services to maintain backward compatibility?
  2. 2Across multiple teams, some services use `[User]!` while others use `[User]`. What governance and tooling would you put in place to enforce consistent nullability contracts?
  3. 3Discuss the long‑term maintenance trade‑offs of being overly strict with non‑null modifiers in a public API.

Follow-up Questions

  • Can you give an example of a breaking change caused by altering a modifier?
  • How would you test that your nullability expectations are met in production?
  • What GraphQL tooling helps catch mismatched type modifiers early?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.