About

Cloudflare supports serverless sockets (source)!

The storage and socket implementations differs substantially to AWS so a decent amount of work would need to be done (e.g. #7).

I've made some headway but it would be first good to know if there is demand for something like this.

I'm using architect for my dev environment and infrastructure management. The dev environment has a api gateway, ddb, lambda and sns, simulators. They're incredibly enjoyable to use locally. However, sending websocket messages in the dev environment doesn't work the same way as it does it production and I need to use it's method instead of the AWS Manager object directly.

I'd like to be able to provide my own async function to send messages, so I can use subscriptionless with architect.

The hook could be used to modify the message or prevent sending. I made up some trite examples of why you might want it, but I bet there are real use cases besides the dev server. And of course the simple case of "if the hook is set, just use that hook" works for me.

const instance = createInstance({
  /* ... */
  onSendMessage: async ({ message }) => {
    // prevent sending
    if (containsSensitiveData(message)) {
       return false
    }
    // send through another channel?
    if(highPriority(message)){
       await fastSend(message)
    }
    // send normally
    return message
  },
});

Happy to do the PR (or not) if this is something you'd add to the project.

About

New directives which have surpassed the RFC stage of the spec.

Resources

• blog post
• rfc
• urql client implementation

Shouldn't require any changes to the graphql-ws spec or client but I've brought it up anyhow - enisdenjo/graphql-ws#224

About

In the case where a ping message is attempted but the connection is no longer open (here), the state machine should close cleanly.

firstly, thanks for this package, it seems a lot more promising than aws-lambda-graphql which we're currently using. I've followed all of the setup steps and I've got our API deploying w/ subscriptionless, but I'm getting the following error when calling instance.publish:

One or more parameter values were invalid: Condition parameter type does not match schema type

I think this is a dynamodb error...has anyone encountered this?

About

For the most part, the information being persisted in DynamoDB isn't useful for anything other than simulating a stack in memory.

DynamoDB supports TTL for cleaning up old data. In our case, we can be fairly confident that any data that is over 2 hours old is stale due to this exceeding the connection duration limit imposed by AWS

Changes

• Add TTL option to createInstance which takes the number of minutes(?) to be appended to the creation time for TTL value (default 180)
• Add TTL values to datamodels
• Update serverless example to use TTL
• Update terraform example to use TTL
• Update example project serverless config to use TTL

Loving the library! I'm trying to add filters to my subscriptions, but can't seem to understand the format.

Would it be possible to have the example in the repo use it?

I also noticed that since it doesn't return an AsyncIterator, typings kinda fail for graphql-codegen generated types

Currently the Management API endpoint is hard-coded to be the supplied domain name, likely since it'd be the same execute-api URL. However I'd like to map the front-facing WebSocket API to a custom domain and supply the execute-api URL myself (I use AWS CDK and could easily pass-through the URL via env vars).

I think it would be around this area: https://github.com/andyrichardson/subscriptionless/blob/master/src/utils/aws.ts#L28

I've been using the Altair graphql client and it's got a behavior. If a websocket url is set it uses it for all queries, mutations and subscriptions. I looked into the graphql-ws client and it's an option to turn on and off. However, queries and mutations throw an error as they don't have a subscribe method.

TypeError: field.subscribe is not a function

About

It would be nice to add support multiple storage mechanisms.

Example

import { createInstance } from 'subscriptionless';
import { DynamoDBPersistence } from 'subscriptionless/dynamodb';

const instance = createInstance({
  schema,
  storage: DynamoDBPersistence({
    dynamodb,
    tableNames: {
      connections: 'my_connections'
    }
  })
});

Notes

Whether this is of any value still remains to be seen.

Drop a comment if you have a use case where something other than DynamoDB would be of use.

I'd like the connectionId to always be availble in the context if possible, so I can do tracking of connections to auth information in the connectionParams.

About

Resolvers should be called with an array of events (due to batching of events).

Note: Needs exploration to see if this is necessary and/or common practice

Example

Before

{
 // ...
  resolve: (event) => {
    console.log(event) // { topic: 'MY_TOPIC', payload: {} }
  }
}

After

{
 // ...
  resolve: (events) => {
    console.log(events) // [{ topic: 'MY_TOPIC', payload: {} }]
  }
}

About

Ping/Pong

For whatever reason, AWS API Gateway does not support WebSocket protocol level ping/pong. This means early detection of unclean client disconnects is near impossible.

(graphql-ws will not implement subprotocol level ping/pong) (which is understandable).

Socket idleness

API Gateway considers an idle connection to be one where no messages have been sent on the socket for a fixed duration (currently 10 minutes).

Again, the WebSocket spec has support for detecting idle connections (ping/pong) but API Gateway doesn't use it. This means, in the case where both parties are connected, and no message is sent on the socket for the defined duration (direction agnostic), API Gateway will close the socket.

A quick fix for this is to set up immediate reconnection on the client side.

Feature request on AWS DIscussion forums

I'm trying to reject a subscription based upon the arguments to the subscription.

My code looks like this (using nexusjs)

export const watchChannel = extendType({
  type: 'Subscription',
  definition(t) {
    t.field('watchChannel', {
      type: Channel,
      args: {
        id: nonNull(idArg()),
      },
      async subscribe(root, args, context){
        console.log({ root, args, context })
        const { id } = args
        const { db } = context
        if (!await db.channel.get(id)) {
          throw new Error('Unknown channel')
        }
        return subscribe('NumbersStationUpdate') 
        // you could call it - doesn't matter 
        // return subscribe('NumbersStationUpdate')(root, args, context)
      },
      resolve({ payload }) {
        return payload.num
      },
    })
  },
})

• The typedef of subscribe is a (root: any, args: any, context: any) => Promise<AsyncGenerator<T>> (optional promise I believe). The SubscribePsuedoIterable return doesn't satisfy that. Additionally the T types the input to resolve() in nextJs it would be nice to control that.
• I know we have other hooks, like onSubscribe for example but it can't choose what we subscribe to, as that's static on the subscribe.definitions property - I'd like it to be dynamic
• Ideally I'd get an error event and maybe a complete event? (I'm a little light on the protocol it doesn't seem to specify the correct behavior) Currently the subscribe function doesn't execute. And Errors in the onSubscribe hook disconnect the websocket instead of providing an error event.

I'd like to propose an alternative. If the function doesn't have a .definitions property, execute it (and resolve it) and see if the result has a .definitions property, then create the subscription objects.

Also we can provide a finished Async iterator from subscribe() so the types check out and it just wont do anything, but then we could allow a typed response from subscribe

Thoughts?

About

For now, all user-provided event handlers are executed sequentially.

await onSubscribe(); // User side-effect - blocking
// ...
// subscriptionless handling logic

It would be nice to have the option between:

• sequential execution (user handler -> subscriptionless handler -> response)
• concurrent execution (user handler and subscriptionless handler -> response)

Note: onConnectionInit handler should always be executed sequentially for authentication purposes

From what I can gather from the README, this seems like it's a replacement to running a GraphQL Server, like Apollo, and executing Queries/Mutations over WebSocket as well.

Would it be possible to run it alongside an Apollo instance, purely to handle Subscription? My immediate thought was to just pass the same schema to createInstance that I do to Apollo, and use createInstance for the publish function via my existing Context.

About

API Gateway's current socket closing functionality doesn't support any kind of close code or close reason. Along with this, graphql-ws won't support error messages (which is understandable).

Feature request on AWS Discussion Forums

Constraint

Because of this limitation, there is no clear way to communicate subprotocol errors to the client.

In the case of a subprotocol error the socket will be closed by the server (with no meaningful disconnect payload).

About

For example, users might want to let the frontend know what about the ping/pong interval.

Currently the onConnectionInit response does not have any impact on the acknowledgement payload