Reusability & Composition: Multi Mesh vs Mega Mesh

[JustusNBB]

I am at the brink of generalizing usage of graphql-mesh in my company, spawning opportunities and questions -
coming from here: #2606 really need to load off some of the topics it spawns ;)

I hope these definitions may help you to understand the context, okay maybe the names are also a bit ridiculous^^:

Multi Mesh

Recomposable Mesh parts, e.g. templating the .meshrc file with a set of parameters to achieve variable source APIs

Mega Mesh

The One Graph to rule them all, supports all the use cases alongside each other, the mesh itself allows reconfiguration to fit all needs

So if I want a Multi Mesh, I think I would push this ticket #2103 to start adding tools "above" the Mesh, controlling and adapting it. I would like to know what other approaches you would take for this? - I could even imagine Ansible to work for this task :P

The Mega Mesh seems to be the most straight forward, but then all reconfigurability needs to be provided out of the box, and the Mesh should somehow feature subset selection for the SDK generation (because every use case just uses a subset of the Mesh) and even the validation.

So generally, what do you think is the better approach, do disadvantages of the "Mega Mesh" and flexibility favor the "Multi-Mesh" and managing its additional complexity with more tooling?
Does this relate to graphql-modules?
I think it's not the same question as "Federation versus Stitching", but they might be related? Is there anything else I am missing about the topic considering an ever growing big Mesh?

[JustusNBB]

So while I am still looking for a good general solution for the grand schema of things and the future, I have at least found a working one for my current schema validation issues "only shows integrity errors of one source at a time" - going into the direction of a Multi Mesh:

• create subfolders with .meshrc.yml files (only single source each, no extras)
• add validate-x scripts for each using --diroption, e.g. mesh build --dir x && mesh validate --dir x

This is just a workaround but it already cries for monorepo tooling...

I would still prefer @ardatan solution:

mesh validate runs the same GraphQL Schema generation process like mesh build does. When one of the sources fails, it stops because it throws an error from getMeshSource.
If we want to have that kind of validation process you said, we need some refactor on handlers such splitting the part using MeshStore and generating GraphQLSchema from it so mesh validate can run only the part MeshStore is used.

[JustusNBB]

Update:

only shows integrity errors of one source at a time

this is fixed with #2849

Also I don't need separate mesh folders for single service validation:

sources:
  - name: GenericSingleServiceValidationPipeline
    handler:
      openapi:
        source: "{env.VALIDATE_GENERIC_SERVICE_SOURCE_URL}"