ardatan / graphql-mesh

🕸️ GraphQL Federation Framework for any API services such as REST, OpenAPI, Swagger, SOAP, gRPC and more...
https://the-guild.dev/graphql/mesh
MIT License
3.3k stars 347 forks source link

Mesh SDK boilerplate generation & nx monorepo integration #2103

Open JustusNBB opened 3 years ago

JustusNBB commented 3 years ago

Is your feature request related to a problem? Please describe.

nx monorepos already have a great integration for GraphQL (e.g. Apollo and NestJS). But GraphQL Mesh is not part of this yet!

Describe the solution you'd like

Alike this stack, create nx plugins to run mesh commands on libraries (and apps) through nx:

Describe alternatives you've considered

I am not sure if this could be extended to make it the default collection (in nx workspace.json), I am mostly interested in the integration as a library, but I want the ability to run mesh commands through nx, and I am still a beginner with nx tooling. There could be an easy way to use existing @nrwl/node executors without creating new nx plugins.

Additional context

An nx monorepo setup has many advantages, namely shared package dependencies and tooling to tend them: graph affected modules! I also like nx's approach because it features many preset conventions and it hides babel/webpack complexity.

nemonemi commented 3 years ago

I'd appreciate this as well.

I might also be willing to do it if the documentation on NX website was better. https://github.com/nrwl/nx/issues/5718

JustusNBB commented 3 years ago

Example dependency chain (to be managed by nx): App(s) -> Library -> Client SDK -> Mesh Default app could be a custom console application to keep it simple (could be anything that uses the library or reuse one of the react examples?), and a secondary app could showcase the GraphiQL or Apollo Playground for the Mesh.

I just recently extracted GraphQL Mesh out of my nx repo because using a library with a generated mesh SDK allows for that, still it seems I could take advantage of an nx setup for the new library project, but I am missing a reasonable nx default collection again - is it just react to pave a path for GraphiQL customization?

Is that all the ways we can use a mesh for? Would it generally be better to have a "mesh-only" project that creates reusable npm artifacts (and then using that in another project with or without nx)?

I've started creating validation pipelines that will be chained to other internal projects, creating a project pipeline cascade (yes the new mesh validate stuff becomes even more useful if you connect it to the right triggers :D)

So it has its upsides not to "monorepo everything" (keeping a clean project scope) and splitting things up. Extracting - ejecting - the mesh from the monorepo should be possible and could be done in different ways (creating another new monorepo to keep the tooling or compressing to a more simple setup without the nx tooling).

  1. nx generate mesh project|lib|playground-app
  2. nx generate importing a mesh
  3. nx eject mesh creating a new project

As a test, we could apply 2. & 3. to any (all) the mesh examples (roundtrip add nx then remove nx).

Also see Multi/Mega Mesh discussion: https://github.com/Urigo/graphql-mesh/discussions/2618

domjtalbot commented 1 year ago

I've created a plugin that will hopefully help with this feature — nx-mesh. I also had projects which used Nx & GraphQL Mesh. Those projects initially had complex scripts to manage the build process within my Nx repo, so I created a plugin to make things easier.

I aimed to create a plugin that makes using GraphQL Mesh with Nx, as easy as using Next.js with Nx.

Existing features include — with more in the works:

ardatan commented 1 year ago

@domjtalbot That's very interesting! Would you create a PR to our docs that points to your project?

domjtalbot commented 1 year ago

I'd be more than happy to do that, @ardatan! Where would be the best place in the docs to list it?

ardatan commented 1 year ago

Sorry for the late response @domjtalbot ! Where would be the best place for you?