visit
One of my side projects involves writing a around the Universal Chess Interface (). I originally developed a mock implementation and . That used version one of Apollo’s client/server stack, which . One of the biggest changes was the subscriptions interface and implementation, and I struggled for many hours to get that to work. Part of the problem is that the documentation is not very complete and rather scattered. This post will cover the most basic implementation of subscription service and the client code that uses it.
On line 12 an ApolloServer is created, with a schema and resolver passed in. The call on line 17 passes in the express application created on line 9. Finally, an http server is created to handle the web socket interface to the subscription service, which is created on line 22.
The schema is very basic: go will return a string acknowledgment, but behind the scenes it will fire off a method that sends publish notifications to subscribers. Subscribers subscribe through the info subscription API.
We can see how this works in resolvers.js:
I’ve made the resolvers deliberately simple. For example, the asyncIterator method from PubSub is quite sophisticated (it supports filters and authentication, for example). Since it is already , I won’t delve into various options here. All the resolver above does is to publish an infoTopic to all subscribers, passing info objects as the body of the subscription (line 10).
To test, I’ll open Playground in Chrome, at Within Playground you can open up multiple tabs. For the first, I’ll subscribe to the infoTopic:
When this command is played, you will see a ‘Listening …’ response in the right pane, as shown above. Now you’re subscribed.
Open another tab within Playground and query go:
This sends back a response of “going”, so everything is okay. Now, going back to the subscription tab, you will see the published output:
The fetch.js code pulls in a lot of interdependent modules. For the test operations, I use (line 6) to handle the interface between the server (which has to be running, btw 😉) and the tests’ GraphQL operations. There are actually two interfaces here: one to handle query and mutation requests vis HTTP (lines 21–27), and another that goes through a web socket to subscribe to a topic (lines 29–37).
Most of this comes from the , but you will have to install a few additional modules I neglected to mention earlier:The node-fetch module implements the HTTP that’s becoming a standard. The ws module is a WebSocket implementation for Node (there are others), and gql is a template literal tag that you can read more about .
The test itself is pretty straightforward: we first subscribe, then go:
The hander object (passed to the subscribe method on line 26) is what receives the publish notifications. When the last published message is received, the test process is terminated (line 15).