GraphQL and NestJS both emphasize modularity. Which statement best explains why GraphQL fits well with NestJS's architecture?
Think about how both GraphQL and NestJS organize code and define APIs.
GraphQL uses schemas and resolvers that fit naturally into NestJS modules and decorators, supporting clear separation of concerns and modular design.
In a NestJS app, you add the GraphQLModule with autoSchemaFile enabled. What is the main effect on the app's behavior?
import { GraphQLModule } from '@nestjs/graphql'; import { Module } from '@nestjs/common'; @Module({ imports: [ GraphQLModule.forRoot({ autoSchemaFile: true, }), ], }) export class AppModule {}
Consider what autoSchemaFile does in NestJS GraphQL setup.
autoSchemaFile tells NestJS to generate the GraphQL schema automatically from your code, enabling GraphQL playground and queries.
Which NestJS lifecycle hook is best suited to initialize resources before a GraphQL resolver handles a request?
Think about when you want to prepare resources before any resolver runs.
onModuleInit() runs once when the module starts, making it ideal to set up resources needed by GraphQL resolvers.
Which code snippet correctly defines a GraphQL query resolver in NestJS?
import { Resolver, Query } from '@nestjs/graphql'; @Resolver() export class SampleResolver { @Query(() => String) hello() { return 'Hello World'; } }
Check the NestJS GraphQL docs for minimal resolver syntax.
The code uses @Resolver and @Query decorators correctly. The method returns a string synchronously, which is valid.
Given this resolver code, why does the app throw a runtime error when querying 'greet'?
import { Resolver, Query } from '@nestjs/graphql'; @Resolver() export class GreetResolver { @Query(() => String) greet() { return this.message.toUpperCase(); } private message: string; }
Check if all properties used in the method have values before use.
The 'message' property is declared but never assigned a value, so accessing toUpperCase() on undefined causes a runtime error.