Mercurius support

[Goopil]

Is your feature request related to a problem? Please describe. As you may now, nestjs graphql support both apollo and mercurius as a graphql server. Do you plan to support both ?

I've made some tests and the nestjs-query pretty much already support it. The only thing that would require some modification is the graphql definition.

Have you read the Contributing Guidelines?

yes :)

Describe the solution you'd like

The query & mutations works out of the box pretty much. I did some test on the original package, not on your fork. Only the subscription definition is a bit different on a mercurius server.

On the plus side.

• Mercurius is a lot more performant.
• you can use subscriptions on a federated gql server

Additional context

I would be glade to help has this package make me gain a lot of time in setting up projects.

Let me know what you thing

[TriPSs]

Hi, I would be very interested in that actually :)

If I understand correctly only the subscriptions are not working? The required changes, is that something we could do inside the existing one or would it be a better idea to split it.

[Goopil]

Hi,

I'm really late in my reply. I hope you don't take it to earth.

Ok so for a proper support. We would have to do a lot of update.

first migrating to @nestjs/graphql@10.* (to have access to the new )

This come with a lot of changes in dependencies to.

just y couple:

• [email protected]
• [email protected]
• @apollo/gateway > 0.44

and so on

As you are using this package in production already. Are you keen to upgrade your project ?

What are you're plans ?

[TriPSs]

Hi, check my last PR #26, this updates a lot of deps. I think the deps you require for the update are updated there.

I'm using this actively in production (multiple projects atm) and have no plans of migrating away, I only want to expand with new features and improve the existing code.

The current status is that I'm testing the TypeORM upgrade in my newest project, this looks all good so I need to update some peer deps to be correct to (with your PR to), I'm also trying to finish one additional feature that I wanted related to grouping aggregated data correctly when grouping by dates.

After that is all done, release as v2 and continue on the path to updating more deps and more features/improvements :)

[Goopil]

Dully noted.

I will have a look at #26 and start from there. At wich point do you plan to merge #26. Is there still a lot to do ? If yes, do you keep a list of what you need somewhere ?

[TriPSs]

My plan is to finish and merge the PR tomorrow.

[TriPSs]

The PR is released, v1.0.1

[Goopil]

Todo

• Duplicate (properly) the tests suits to validate fastify support (express Apollo, fastify Apollo, fastify mercurius)

• Upgrade deps to @nestjs/graphql 10+

• tailor an error handler having the same format at as Apollo errors.

• detect what gql server is used (Apollo / mercurius) And fix the subscriptions definition (appolo use toAsyncIterator method to define a subscription. Mercurius use subscribe directly and the payload is different.)

• Validate the pubsub injection

[Goopil]

The fastify implementation seems broken at the moment. @nestjs/plateform 9+ use fastify 4+ but apollo server is not. I wanted to start with the full support of both plateform before starting the work on mercurius. People are asking for depencencies update and support for nest 9+. And this break at the moment. :( sad story

We know that work but all packager will complain with improper packages version.

Should we wait a bit ?

[TriPSs]

Think we will have to wait for this pr to be merged.

Thanks for the heads-up, was just planning in updating one of my API's to nest 9 but will have to wait to since that project uses apollo to.

[smolinari]

I'd like to suggest Apollo with Fastify simply not be supported. It's obvious the Apollo team isn't supporting it as anything but a minor enhancement and thus, will always be a fight for our patience with them (which has always been the case with their server packages. Terribly slow development....). I'd like to suggest keeping Mercurius as the Fastify GraphQL server only. The only downside I see is because Apollo federation 2 won't be supported by Mercurius. But, it's because the Apollo team put a poor OSS license on it and have a patent pending on Federation 2's design, which is, IMHO, stupid for software in general and for sure for OSS. And, it seems the maintainer of Mercurius sees it the same way.

Still, Mercurius is superior to Apollo currently for Fastify, IMHO, so I'd concentrate mainly on that.

Scott

[Goopil]

Thanks for the headup. The goal was always mercurius to be honest. I wanted to validate some cases using fastify. It look like o will have to go straight to it.