Why two different packages: schema-stitching and graphql-mesh?

[cloudcompute]

Hi @ardatan, @Urigo AND @dotansimha

You are working on both these projects:
graphql-mesh and schema-stitching

The functionality offered by schema stitching (federation) is actually a subset of graphql-mesh. But graphql-mesh is not using schema-stitching as one of its dependencies. Why is it so?

My viewpoint is that a Graphql gateway may also be implemented by combining

• Yoga & its plugins like sofa
• schema-stitching
• envelop and its plugins
• some functionality from graphql-mesh

The objective is to keep a single codebase.. for example, as of now, rate-limiting functionality is implemented (as plugins) in two different codebases: graphql mesh and envelop. Does it make sense?

Thank you

[Urigo]

You are right, GraphQL Mesh is the future of our offering
Schema Stitching was used initially but now we've created an implementation that also supports the new Fusion spec and the composite schemas working group latest work
So basically now GraphQL Mesh fully supports Apollo Federation, Fusion and the future spec

I would recommend simply using GraphQL Mesh as your gateway of choice

I hope its clear

We are soon going to update our messaging around this on our websites and docs as we are getting ready for 1.0 version

[Urigo]

I would love to hear about your use case and what you are planning to use GraphQL Mesh for!

[cloudcompute]

@Urigo

Thank you for the answer. Ideally speaking, I am looking for a full-fledged API gateway that has the functionality

• offered by Apisix It has features like OAuth, Authentication, Load Balancing, Circuit Breaking, Observability

• Graphql support that includes schema stitching.. data coming from several sources including microservices, webhooks, gRPC, REST

• Authorization support: fine-grained permissions like ABAC

PS: As an alternative to Graphql, I am exploring tRPC. While Graphql is a wonderful technology, it invloves a lot of work though.

I went through the Hive code (Guild project). It is using both tRPC and Graphql, could not understand why!

[Urigo]

tRPC and GraphQL serve very different use cases
I think the first question you should decide is if you want GraphQL or not
The more you share about your use case the I could point the reasons to use GraphQL or not

[cloudcompute]

Hi @Urigo

Use case is to create an application having these modules: Product Catalogue management, Sales and Purchase (including RFQ, Quotations etc.), and Inventory/Stock management.

Thank you.

[Urigo]

Do you imagine the backend services to start as a single service at the beginning?
what programming language will it be written in?

[cloudcompute]

Java. Yes, single service at the beginning.