federation VS graphql-live-query

I feel like we ran into this recently at work but not with custom scalars etc. My colleague raised an issue for it. Hope this helps in some way.

as per the Github issue here. However I have trouble understanding this statement. Why can't the gateway pick and choose which input fields are routed to each subgraph? Isn't it the responsibility of the supergraph SDL and the gateway to do exactly this, this same way it does for entities? What limitations are there that make merging input types using the union strategy not viable?

Federation comes with its own specification and directives as part of it which helps people to define all of the relations between multiple GraphQL entities so that the Apollo Gateway can combine them all together without having to modify the GraphQL gateway and also functions like __resolveReference which helps in resolving an entity with its reference as specified by the directives.

There are even more implementations of live queries available by now. e.g. https://github.com/samsarahq/thunder (go) or https://github.com/n1ru4l/graphql-live-query (JavaScript).

Please compare with modern competitor: json-patch-plus https://github.com/n1ru4l/graphql-live-query/blob/main/packa...

Also note that subscriptions are not the only way to do real time communications in GraphQL. There are also things like Live Queries with great libraries like this from Laurin which you can use

Last but not least, I also created a GraphQL over Socket.io (https://github.com/n1ru4l/graphql-live-query/tree/main/packages/socket-io-graphql-server) transport. I am using this in two smaller apps with a maximum of 10 concurrent users and did not encounter any issues with stale data yet. Maybe this might be somethign you are looking for.

So after having tried to answer you questions (instead of just telling you to not use WebSockets, although that wasn't your question 🙃). I also wanted to point you to a "new" way of handling real-time data with GraphQL that I am experimenting one. https://github.com/n1ru4l/graphql-live-query

There will always be an overhead for sending the mutations via a Post http request vs sending them over the already established WebSocket connection. graphql-ws is not only a subscription transport but can be used for any GraphQL operation including queries and mutations. In real-time applications I tend to use my own GraphQL over Socket.io transport (https://github.com/n1ru4l/graphql-live-query/tree/main/packages/socket-io-graphql-server)