How to pass a header to typegrapqhl resolver from tests

[i-void]

There is a simple resolver like this

  @InjectContext()
  protected $ctx?: PlatformContext;

  @Query(() => [User], { nullable: true })
  async users(): Promise<Partial<User>[] | null> {
    console.log(this.$ctx?.request.raw)
    const users = await this.repo.user.findMany()
    return users
  }

and we are creating a test client like this

export const createTestClient = (
  server: ApolloServerBase<TypeGraphQLService>
): ApolloServerTestClient => {
  const executeOperation = server.executeOperation.bind(server);
  const test = ({ query, mutation, ...args }: Query | Mutation) => {
    const operation = query || mutation;

    if (!operation || (query && mutation)) {
      throw new Error(
        "Either `query` or `mutation` must be passed, but not both."
      );
    }

    return executeOperation({
      // Convert ASTs, which are produced by `graphql-tag` but not currently
      // used by `executeOperation`, to a String using `graphql/language/print`.
      query: typeof operation === "string" ? operation : print(operation),
      ...args,
    });
  };

  return { query: test, mutate: test } as ApolloServerTestClient;
};

we are using koa and tries to make request like this to this test client

import "@tsed/platform-koa";
...
const GET_USERS = gql`
  query {
    users {
      id
      email
      username
    }
  }
`;

...
    request = createTestClient(apolloServer);
...
    const response = await request.query({
      query: GET_USERS,
      variables: {},
    });

But we cannot set headers for this query. How could we manage to send headers with this query and read from this.$ctx?.request.raw in resolver?

[Romakita]

See https://tsed.io/docs/request-context.html

[Romakita]

Because you trying to do something that is not covered by Ts.ED in fact.

[Romakita]

You are not supposed to consumed tsed context in a resolver which is a part of typegraphql not Ts.ED ;)

[i-void]

I spent so much time to configure Ts.ED to work with GraphQL but at the end I realized that Ts.ED doesn't support subscriptions also. That was very bad for me to understand that and figured out Ts.ED's graphql support is missing lots of things. Then I switched to Graphql Yoga and now I'm very happy. Just a feedback; you should remove graphql support if you couldn't support it properly. It makes people to waste their times. ;)

[Romakita]

I think you misunderstood where is the problem.
Ts.ED doesn't support typegraphql. It use TypeORM so any question related to graqhql should be addressed to typegraphql and not to Ts.ED itself.

I already answer you about that. I'm not responsible if you haven't looked on typegraphql to solve your issue. When you said "tsed doesn't support subscription", again you clearly misunderstood where is the graphql feature responsability 😔 (here it's typegraqhQL again)

Also, my point of view is always the same (and described in the issue guideline, but you haven't read that, because you haven't opened an issue). Create repository example, afd your expectation and I'll take a time to help you. And you know I always help the community when it's possible.

It's a shame because your question could have led to a better answer if you had taken the time to make a complete issue ;). it would have helped someone else. On the principle that I don't work on graphql all the time and that your requests are not as obvious to me as to you who are in the heart of the matter. that's why I insist on creating repo example ;)

I'm happy if found a way to solve your issue with another framework. But I'm not really happy about your anwser, which does not really encourage to improve things.
See you

[Romakita]

@i-void TypegraqhQL support subscription https://typegraphql.com/docs/subscriptions.html for your information. So your comment seems to be wrong ;)

[oereneli]

That document says nothing about Ts.ED you know. I understand from your messages that you have little knowledge about Graphql. If you have a framework and you claim that you support Graphql, that framework can handle graphql requests (including subscriptions) with request headers passed to your graphql handler's context (this is the way others doing this). Also Typegraphql is an only a parser for schema, in Graphql world there are much more parsers like that. But mostly they are common in their api. And your FW should adapt to this API and well document it if you claim you have support graphql properly. And you are wrong again, subscription is the responsibility of Ts.ED to work with any of those parsers (you can inspect graphql yoga docs for this). At the end, you don't need to support graphql. And if I were you, I wouldn't. Because it is a huge complex beast and hard to maintain, document and test.

[Romakita]

The subscription feature is a part of TypeGraqhQL so it's supported. I given you a documentation link. I don't know why you said isn't supported. But in this case show me how it is not supported. and probably I'll have a solution for that.

I understand the point that the documentation must be improved but Ts.ED use Typegraphql so all feature supported by this framework is available. If typegraqhql support request header, so it's possible with Ts.ED. You just haven't looked on the right project documentation (I'll improve the doc). I'm not really aggree with you about TypeGraphQL that is just a parser.
It provide resolver, query, mutation, input validation, request manipulation and it's own DI. He do more than a simple parser.

I haven't rewritten all TypeGraphQl documentation on tsed website because It doesn't make sense.

The next action is to simply clarify the documentation. Your initial question is outside of the Ts.Ed framework scope like the the subscription is because it's already supported by typegraqhql.

Last point, it's interesting that you mention GraphQl yoga, it's the same framework as GraqphQL nexus, Ts.ED provide a way to configure this framework.

I could have offered exactly the same thing with yoga (if I had known about it) but probably who wouldn't have asked me a question.

I'm happy to discuss that, because I don't use really graphql. It was a requested feature by the community and I never had the will to support it but rather to open the voice to a use and that it is improved over time by the community.

In the future I would like to do without typegraphql and switch to something easier to integrate and on which a question like yours would actually be within the scope of the Ts.ED framework;)

[Romakita]

@oereneli This PR answer to your issue. Finally, it was easy to inject context in the resolver by reading the typegraphql doc here:
https://typegraphql.com/docs/middlewares.html#global-middleware or using @Ctx typegraphql decorator:

import {ResolverController} from "@tsed/typegraphql";
import {Arg, Ctx, Query} from "type-graphql";
import {Recipe} from "../types/Recipe";

@ResolverController(Recipe)
export class RecipeResolver {
  @InjectContext()
  private $ctx: Context;

  @Query((returns) => Recipe)
  async recipe(@Arg("id") id: string, @Ctx("req.$ctx") $ctx: PlatformContext) {
    $ctx.logger.info("Hello world");
    console.log($ctx.request.headers);
  }
}

The new documentation on Ts.ED will clarify this part. But settings header using $ctx isn't the normal way in a TypegraphQL context. TypeGraphQL provide his own @Ctx() decorator.

On the subscription feature, you've right, Ts.ED doesn't support it if you want to use Websocket. Using multipart it should works because Apollo embed it directly!

If developers look over websocket support, this PR #2503 add it.

Ultimately the main concern of this discussion was not having opened an avenue to request an improvement of the existing modules.
I obviously encourage improving the modules provided rather than deleting them. Suggestions are always welcome and PRs also. I not having the possibility of knowing everything on all the subjects it is normal that everything is not complete. That’s what feature requests are there for!