Live Queries and Subscriptions

I am trying to use GraphQL Subscriptions and Live Queries and so far everything seems quite exciting, however we have some slow background processes and we use inngest to trigger them. What I want to do is notify specific GQL subscribers, but how do I get the context?

In a mutation we get the context as the 2nd parameter of the function like in the example:

export const sendMessage = async (
  { input }: { input: SendMessageInput },
  { context }: { context: { pubSub: NewMessageChannelType } }
) => {

What I need is to be able to get this context from other functions (API integrations receiving notifications from other systems) as well as inngest functions

What I found is that I can import context from here:

import { context } from '@redwoodjs/graphql-server'

And it has liveQueryStore just like the context from the example:

export const bid = async (
  { input },
  { context }: { context: { liveQueryStore: LiveQueryStorageMechanism } }
) => {

but it’s missing the pubSub. So my first question is - where does “pubSub” live and what should I import so I can call pubSub.publish('newMessage', roomId, { from, body })

This leads me to my second question: When I invalidate a live query, how is the key associated with the query?

So basically how does the server “know” what query to invalidate when I do this:

  const key = `Auction:${auctionId}`
  context.liveQueryStore.invalidate(key)

when the auction query signature is like this:

export const auction = async ({ id }) => {

And how will the key look if I have multiple params? Can I specify which ones should be part of the key?

OK A found where pubSub “lives” here:

import { pubSub } from '@redwoodjs/realtime'

And that worked.

Now that I solved my first problem I have a new one - after deploying the app on FlightControl (AWS EC2 instance) - I see the following error:

6:50:57 AM {"level":50,"time":1705553457119,"pid":49,"hostname":"ip-10-192-11-73.us-west-2.compute.internal","name":"graphql-server","msg":"GraphQL operation type \"subscription\" is not allowed."}

Hi, I think I was perhaps chatting with someone else on your team (maybe?) about deploying rio FC with this error message in another channel.

We wanted to have some logging added to ensure that the right server file was being run in production.

It was working in local dev.

The reason was that the Realtime config in the GraphQLServer config will automatically allow the subscription operation.

See: redwood/packages/graphql-server/src/createGraphQLYoga.ts at a9705c1b25d780b20e7670d73364ab607d4d3520 · redwoodjs/redwood · GitHub

So, the suspicion is that FC may not be running that server file?

You could also force the allow that operation:

But then it’s like realtime isn’t setup correctly.

But, I didn’t get any feedback yet if that was the case (about 5 days ago).

Hi, thank you for your response.

We figured out that part thanks to the help from the guys from FC. Sorry for not posting it here - I’m still working on this feature and was waiting to get all done before describing what I did.

Adding subscription to the allowedOperations didn’t help. (I.e. adding this had no effect:

   allowedOperations: [
     OperationTypeNode.QUERY,
     OperationTypeNode.MUTATION,
     OperationTypeNode.SUBSCRIPTION,
   ],

As they advised, we set host to ‘0.0.0.0’ when starting fastify.listen.

  const port = enableWeb ? redwoodConfig.web.port : redwoodConfig.api.port
  const host = redwoodConfig.api.host 
....
  fastify.listen({ host, port })

and added this to redwood.toml

[api]
host = "0.0.0.0"

Also instead of starting yarn rw deploy flightcontrol api --serve we changed that to node ./api/dist/server.js

Now the only thing I still fail to understand is how to generate the key for a LiveQuery with multiple parameters and can I invalidate multiple queries at once? I.e. invalidate queries with first two parameters having specific values and ignore the 3rd parameter to the query.

For example lets take the Auction example. If we have a query listing all auctions by city, state, category and search term, once an auction is complete we want to update this query (we know the city, state and category of the auction that finished, but search term can be anything).