What is the difference of resolver/service in nestJS using graphql?

Question

I do not understand the difference between a resolver and a service in a nestJS application using graphQl and mongoDB.

I found examples like this, where the resolver just calls a service, so the resolver functions are always small as they just call a service function. But with this usage I don't understand the purpose of the resolver at all...

@Resolver('Tasks')
export class TasksResolver {
  constructor(
    private readonly taskService: TasksService
  ) {}

  @Mutation(type => WriteResult)
  async deleteTask(
    @Args('id') id: string,
  ) {
    return this.taskService.deleteTask(id);
  }
}


@Injectable()
export class TasksService {
  deleteTask(id: string) {
    // Define collection, get some data for any checking and then update dataset
    const Tasks = this.db.collection('tasks')
    const data = await Task.findOne({ _ id: id })
    let res

    if (data.checkSomething) res = Task.updateOne({ _id: id }, { $set: { delete: true } })

    return res
  }
}

On the other side I can put all the service logic into the resolver and just leave the mongodb part in the service, but then the services are small and just replacing a simple mongodb call. So why shouldn't I put that also to the resolver.

@Resolver('Tasks')
export class TasksResolver {
  constructor(
    private readonly taskService: TasksService
  ) {}

  @Mutation(type => WriteResult)
  async deleteTask(
    @Args('id') id: string,
  ) {
    const data = await this.taskService.findOne(id)
    let res

    if (data.checkSomething) {
      const update = { $set: { delete: true } }
      res = this.taskService.updateOne(id, update)
    }

    return res
  }
}


@Injectable()
export class TasksService {
  findOne(id: string) {
    const Tasks = this.db.collection('tasks')
    return Task.findOne({ _ id: id })
  }

  updateOne(id: string, update) {
    const Tasks = this.db.collection('tasks')
    return Task.updateOne({ _ id: id }, update)
  }
}

What is the correct usage of the resolver and service? In both cases one part keeps nearly a one liner for each function, so why should I split that at all?

Answer 1

You're right that it's a pretty linear call and there isn't much logic behind it, but the idea is to separate the concerns of each class. The resolver, much like a REST or RPC controller, should act as a gateway to your business logic, so that the logic can be easily re-used or re-called in other parts of the server. If you have a hybrid server with RPC or a REST + GQL combo, you could re-use the service to ensure both REST and GQL get the same return.

In the end, it comes down to your choice on what you want to do, but separating the resovler from the service (having thin gateways and fat logic classes) is Nest's opinion on the right design.

Answer 2

Your service help you fetch the data from Database. Your Resolver help to delivery these data to user. Sometimes, the data that you delivery to user not the same with data from Database, so the Resolver will make up these data as user's demand before sending it to user.