What is the difference between @ObjectType() and @InputType() in NestJS GraphQL and why can't you reuse the same class for both?
@ObjectType() defines a GraphQL output type that can contain resolvers, computed fields, and relations. @InputType() defines a GraphQL input type where all fields must be serializable scalars or nested input types. They are distinct schema types and NestJS will throw a runtime error if you try to use an @ObjectType() as a mutation argument.
- 1
@ObjectType() — output only; can contain resolver methods, computed properties, and lazy-loaded relations.
- 2
@InputType() — input only; all fields must be serializable scalars or nested @InputType() classes.
- 3
GraphQL schema has separate type registries for Input and Object types — they cannot be mixed.
- 4
OmitType(User, ['id'], InputType) re-registers fields from an @ObjectType() as an @InputType().
- 5
PickType, PartialType, and OmitType from @nestjs/mapped-types bridge output and input types safely.
Scenario Questions
0-2 years experience
- 1You need to add a new mutation that creates a user. How would you define the DTO class for the mutation arguments using NestJS GraphQL decorators?
- 2If you accidentally annotate a class with @ObjectType instead of @InputType for a mutation argument, what runtime symptom would you expect?
- 3How would you share common fields between a User object type and a CreateUser input without copying code?
2-5 years experience
- 1During a code review you notice a teammate reused the same class for both @ObjectType and @InputType, causing schema generation to fail. Walk me through how you would diagnose and fix it.
- 2You need to add class‑validator decorators to a mutation input. How does using @InputType versus @ObjectType affect where those validators run?
- 3You have a nested object in your schema. Explain why you can't just reuse the nested @ObjectType class for the input and how you would structure the input types.
5-8 years experience
- 1Design a pattern for sharing common fields across many GraphQL object types and input types in a large NestJS codebase while respecting GraphQL constraints.
- 2Your service exposes both read and write APIs for the same domain model. Discuss the trade‑offs of keeping separate @ObjectType and @InputType classes versus using a shared base class with inheritance.
- 3If you need to generate TypeScript client types from your GraphQL schema, how does the separation of @ObjectType and @InputType impact the generated types and client code?
8+ years experience
- 1Your organization is migrating a monolithic NestJS GraphQL API to micro‑services. How would you refactor existing @ObjectType/@InputType definitions to support versioning and cross‑service contracts while avoiding duplication?
- 2Multiple teams need to evolve the same domain model independently. What governance or tooling would you put in place to keep @ObjectType and @InputType definitions in sync without breaking other services?
- 3Discuss the long‑term maintenance implications of tightly coupling business logic to GraphQL decorators, and propose an alternative architecture that decouples the domain model from schema definitions.
Follow-up Questions
- What error would you see if you used an @ObjectType as a mutation argument?
- Can you give an example of extending shared fields without duplicating the whole class?
- How does this distinction affect auto‑generated TypeScript types for the client?