You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: allow runtime errors and validation errors in onSubscribe (reconbot#36)
Change the API of `onSubscribe` to allow returning validation errors (to reject a subscription) and throwing errors to close the connection (usually only happens if there's a big problem).
This came from talking it over at graphql-ws enisdenjo/graphql-ws#226
bonus
- add a timeout for test helpers
This is a fork of [subscriptionless](https://github.com/andyrichardson/subscriptionless) that is built to work with [Architect](https://arc.codes) and tested with the [Architect Sandbox](https://arc.codes/docs/en/reference/cli/sandbox). There's no reason why it wont work with Serverless or other deploy tools but their support is not a goal.
4
+
This is a fork of [`subscriptionless`](https://github.com/andyrichardson/subscriptionless) and is a Amazon Lambda Serverless equivalent to [graphQL-ws](https://github.com/enisdenjo/graphql-ws). It follows the [`graphql-ws prototcol`](https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md). It is tested with the [Architect Sandbox](https://arc.codes/docs/en/reference/cli/sandbox) against `graphql-ws` directly and run in production today. For many applications `graphql-lambda-subscriptions` should do what `graphql-ws` does for you today without having to run a server.
5
+
6
+
As `subscriptionless`'s tagline goes;
7
+
8
+
> Have all the functionality of GraphQL subscriptions on a stateful server without the cost.
9
+
10
+
## Why a fork?
11
+
12
+
I had different requirements and needed more features. This project wouldn't exist without `subscriptionless` and you should totally check it out.
13
+
14
+
## Features
15
+
16
+
- Only needs DynamoDB, API Gateway and Lambda (no app sync or other platform required, can use step functions for ping/pong support)
17
+
- Provides a Pub/Sub system to broadcast events to subscriptions
18
+
- Provides hooks for the full lifecycle of a subscription
19
+
- Type compatible with GraphQL and [`nexus.js`](https://nexusjs.org)
20
+
21
+
## Quick Start
22
+
23
+
Since there are many ways to deploy to amazon lambda I'm going to have to get opinionated in the quickstart and pick [Architect](https://arc.codes). `graphql-lambda-subscriptions` should work on Lambda regardless of your deployment and packaging framework. Take a look at the [arc-basic-events](mocks/arc-basic-events) mock used for integration testing for an example of using it with Architect.
Subscribe is the most important method in the library. It's the primary difference between `graphql-ws` and `graphql-lambda-subscriptions`. It returns a `SubscribePseudoIterable` that pretends to be an async iterator that you put on the `subscribe` resolver for your Subscription. In reality it includes a few properties that we use to subscribe to events and fire lifecycle functions.
@@ -20,40 +43,12 @@ interface SubscribeOptions {
20
43
21
44
-`topic`: The you subscribe to the topic and can filter based upon the topics payload.
22
45
-`filter`: An object that the payload will be matched against (or a function that produces the object). If the payload's field matches the subscription will receive the event. If the payload is missing the field the subscription will receive the event.
23
-
-`onSubscribe`: A function that gets the subscription information (like arguments) it can throw if you don't want the subscription to subscribe.
46
+
-`onSubscribe`: A function that gets the subscription information (like arguments) it can return an array of errors if you don't want the subscription to subscribe.
24
47
-`onAfterSubscribe`: A function that gets the subscription information (like arguments) and can fire initial events or record information.
25
48
-`onComplete`: A function that fires at least once when a connection disconnects, a client sends a "complete" message, or the server sends a "complete" message. Because of the nature of aws lambda, it's possible for a client to send a "complete" message and disconnect and those events executing on lambda out of order. Which why this function can be called up to twice.
26
49
27
50
## Old Readme
28
51
29
-
## About
30
-
31
-
GraphQL subscriptions for AWS Lambda and API Gateway WebSockets.
32
-
33
-
Have all the functionality of GraphQL subscriptions on a stateful server without the cost.
34
-
35
-
> Note: This project uses the [graphql-ws protocol](https://github.com/enisdenjo/graphql-ws) under the hood.
36
-
37
-
## ⚠️ Limitations
38
-
39
-
Seriously, **read this first** before you even think about using this.
40
-
41
-
<details>
42
-
43
-
<summary>This is in alpha</summary>
44
-
45
-
This is Alpha software and should be treated as such.
46
-
47
-
</details>
48
-
49
-
<details>
50
-
51
-
<summary>AWS API Gateway Limitations</summary>
52
-
53
-
There are a few noteworthy limitations to the AWS API Gateway WebSocket implementation.
54
-
55
-
> Note: If you work on AWS and want to run through this, hit me up!
56
-
57
52
#### Ping/Pong
58
53
59
54
For whatever reason, AWS API Gateway does not support WebSocket protocol level ping/pong.
@@ -74,7 +69,6 @@ API Gateway's current socket closing functionality doesn't support any kind of m
74
69
75
70
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).
0 commit comments