search

TriPSs / nestjs-query

Easy CRUD for GraphQL.
https://tripss.github.io/nestjs-query/
MIT License
152 stars 43 forks source link

Mercurius support #13

Open Goopil opened 2 years ago

Goopil commented 2 years ago

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.

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 commented 2 years ago

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 commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

My plan is to finish and merge the PR tomorrow.

TriPSs commented 2 years ago

The PR is released, v1.0.1

Goopil commented 2 years ago

Todo

Goopil commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.