Why two different packages: schema-stitching and graphql-mesh? #6827
Replies: 5 comments 2 replies
-
You are right, GraphQL Mesh is the future of our offering 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 |
Beta Was this translation helpful? Give feedback.
-
I would love to hear about your use case and what you are planning to use GraphQL Mesh for! |
Beta Was this translation helpful? Give feedback.
-
Thank you for the answer. Ideally speaking, I am looking for a full-fledged API gateway that has the functionality
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! |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Java. Yes, single service at the beginning. |
Beta Was this translation helpful? Give feedback.
-
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
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
Beta Was this translation helpful? Give feedback.
All reactions