Mercurius + typegraphql + @Ctx() decorator

[jessekrubin]

How do you get the type of the context when using mercurius with typegraphql where a resolver has a ctx param such as:

  @Query(...)
  async fileexists(@Arg('fspath') fspath: string, @Ctx() ctx): Promise<boolean> {
    return existsPromise(fspath);
  }

[jessekrubin]

Is it an instance of MercuriusContext? How would I modify it?

[mcollina]

Thanks for asking, I have never used typegraphql, so I do not know.

[smolinari]

@jessekrubin - Try out NestJS. There is a Mercurius module and being Nest has a GraphQL code first approach almost the same as TypeGraphQL AND a modules system for DI, it is a step up from TypeGraphQL.

https://docs.nestjs.com/graphql/quick-start
https://www.npmjs.com/package/nestjs-mercurius

Scott

[jonnydgreen]

Is it an instance of MercuriusContext?

It is, yep

How would I modify it?

Are you referring to the type or the value (or both?)?

[jessekrubin]

Both

[jessekrubin]

@smolinari i might give it a look. I tried out nest a while ago and thought super over engineered and not very well documented.

I adore fastify.
Json schema validation is fantastic.
I love how fastify's plug-in system works.
I like that @mcollina writes easy to understand plugins and they basically always work perfectly.
Fastify has a way better name than nest.
Fastify with typescript is a dream.

Why do you like nest? Maybe I will give it another go...

[smolinari]

@jessekrubin - I like Nest, because it offers a modularization system (fashioned after Angular, but that is definitely not why I like it). So, this modularization helps the application be split up smartly for testing and scaling due to its DI container system. And, it is above and beyond Fastify. By that I mean, Nest can use Fastify (or Express) as the HTTP server basis, but Nest builds on top of the web servers and is much more about logic segregation. The fact it can use Fastify under the hood also means all the good plugins for Fastify will also work with Nest. Lastly, if you like how you can decorate stuff to make things happen, like in TypeGraphQL, then Nest is a smart addition in terms of the business logic side of your app, as you can also decorate your resolvers with pipes for validation, guards for auth, and interceptors for transformations, etc. Yes, there is a learning curve as there is with any framework, but once the understanding is there, any team member will have it easier in getting into the code (part of the scaling I mentioned above).

If you are building something to last and grow with Enterprise grade quality, then needing a system like Nest will be an inevitable choice.

Scott

[jonnydgreen]

Both

For the value, you can customise this with the context option: https://mercurius.dev/#/docs/api/options?id=plugin-options

For the type, there are two options I can think of (I'm not sure if it's possible to infer):

• Create a type matching the return type of your context (e.g. Context) option function and use this type as follows:

@Query(...)
async fileexists(@Arg('fspath') fspath: string, @Ctx() ctx: Context): Promise<boolean> {
  return existsPromise(fspath);
}

• Extend the MercuriusContext type using:

declare module 'mercurius' {
  export interface MercuriusContext {
    ...
  }
}

@Query(...)
async fileexists(@Arg('fspath') fspath: string, @Ctx() ctx: MercuriusContext): Promise<boolean> {
  return existsPromise(fspath);
}

Hope that helps :)