graphql-ws VS graphql-spec

There is already a JavaScript implementation for server + client with support for multiplexing from the same maintainer of graphql-ws: graphql-sse

Actually WebSocket is not the only protocol for executing GraphQL subscriptions. There is also a graphql-over-sse protocol, which is much more lightweight, and uses Server Sent Events. A popular implementation of it is the graphql-sse library, which is maintained by the same person as graphql-ws. The setup and API of both libraries is pretty similar.

That said, I feel so close to success that I can't quite give up. I am using graphql-ws as I understand this to be the new standard implementation of GraphQL Subscriptions. However, of course, Apollo subscriptions have not been updated to implement this. So, looking at the Recipes over on the graphql-ws documentation I have found the guide for using Apollo client. However as I am new to Apollo, it is using a lot of terms I am unfamiliar with.

Okay but seriously, if you've fallen down the rabbit hole of Apollo docs pointing you towards one library (subscription-transport-ws) which then points you to another (graphql-ws) , and so on and so forth, then hopefully this helps pull you out.

The most common protocol used today for subscriptions is the Apollo websocket protocol.

GraphQL subscriptions are just web sockets. You can check graphql-ws package if you want something without Apollo dependency. Though I don't understand why you want to not depend on it in the first place.

New GraphQL-WS ✔️

The interesting thing is that we can use any transport for delivering the results to client. The most popular implementation (as mentioned before) is subscriptions-transport-ws. Unfortunately, since it is poorly maintained, the GraphQL Working Group came up with a new implementation over WebSockets, graphql-ws.

Okay, so, how do I use WebSockets to add support for the GraphQL subscription operation? Doing a basic Google search, you’d be faced with a single solution, namely subscriptions-transport-ws. Looking through the repository, checking recent comments, reading through the issues and open PRs - might have you notice the abundance of bugs and their security implications. A summary can be found here.

Have you thought about using graphql-ws instead? It uses the new graphql-transport-ws protocol which also has an open RFC that is discussed in the GraphQL working Groups.

:::note GraphQL Union is available for Types only, not for Inputs. However, the oneOf directive will bridge the gap in the future.

GraphQL is a query language for APIs and a runtime for fulfilling those queries with existing data. GraphQL is a open specification; it is not controlled or managed by a single vendor. GraphQL clients and servers can be written in a number of programming languages. There is no requirement to use particular data stores to persist data.

And with that, while there are definitely more advanced things one can learn about GraphQL, you should be armed with enough knowledge about the GraphQL spec to understand how to use and consume most GraphQL APIs.

Here's an idea: you can use the flat chain syntax. Then you can write the query like this:

What about using @export, as proposed here: https://github.com/graphql/graphql-spec/issues/583?

So check if your server supports the @export functionality, which was also proposed for the spec but not yet approved (unfortunately! this should really be in GraphQL, imo).

What you're requesting is a feature that was proposed for the GraphQL spec: the flat chain syntax. With it, you could possibly do this:

Reference https://spec.graphql.org

GraphQL is a specification that describes: a query language and schema definition language. It's not a programming language capable of arbitrary computation, but is instead a language used to make requests to application services that have capabilities defined in this specification. GraphQL does not mandate a particular programming language or storage system for application services that implement it. Instead, application services take their capabilities and map them to a uniform language, type system, and philosophy that GraphQL encodes. This provides a unified interface friendly to product development and a powerful platform for tool-building.