Using grapqhl-subscriptions with serverless backend

How can we use graphql-subscriptions with a serverless backend like AWS Lambda? In this case, transport using web sockets won't work since a lambda function can't run for long time.

[scf4]

You must have a continuously running server to manage websocket connections. AWS Lambda can handle regular HTTP requests since they're short-lived. Websockets are by definition long-lived.

Edit: It might be possible to run a lambda instance during the lifetime of the websocket, but I can't imagine this would be worthwhile.

[jthegedus]

Given that there are Redis and MQQT subscription packages http://dev.apollodata.com/tools/graphql-subscriptions/external-pubsub.html, are there any tutorials or efforts to create tutorials surrounding the use of managed pubsub services like AWS SNS or GCP PubSub?

Furthermore, as someone using Firebase DB as the storage layer of my GraphQL, is there a way to leverage the real-time part of FirebaseDB through GraphQL on the client?

I am exploring these myself, but curious if others had already attempted this and what the outcome was.

[mattfysh]

Could you use AWS IoT websockets in front of lambda?

[scf4]

@jthegedus Any luck so far?

[jthegedus]

@mattfysh I haven't looked at the AWS IoT websockets service myself. I've used AWS more than GCP but found that GCP PubSub is more generic and therefore easier to understand how it fits into the subscription model.

@scf4 There's a lot of flux with how subscriptions are managed since the finalization of the subscription RFC in the GraphQL spec. I'm trying to keep up with all the changes in the various repos - subscriptions-transport-ws, graphql-js, graphql-subscriptions - to see where exactly the subscriptions state is kept and where a managed pusub service fits. It seems that it should be easier, but the changes are still in progress and there's no point working with the previous implementation as the version built against the spec will be the gold standard implementation.

[dotansimha]

I am not sure this issue has a simple solution.
AWS supports WebSocket connections, and you can combine it with any PubSub implementation (MQTT/Redis).
The main issue here is to keep the connection open with AWS Lambda, because graphql-js (> 0.10.0)graphql-subscriptions and subscriptions-transport-ws can work with any PubSub implementation (just wrap and return AsyncIterator in your GraphQL schema).

[Siyfion]

Surely by its very nature, AWS Lambda deals with short lived connections. Websockets aren't short lived. So perhaps AWS Lambda could deal with all the queries and mutations, and an intelligent Application Load Balancer that routes websockets to a single EC2 instance?

[jthegedus]

The solution I am thinking of for this problem isn't trying to get websockets to work in ephemeral compute services (Lambda/Cloud Functions/Azure Functions), it's to move the logic of the connection state to a managed service. A non-websocket pubsub system that enables server to client push of data is what is required. So far from my research, the options from the big 3 include:

Azure: Event Hub or Service Hub
AWS: SQS with SNS (I need to read more about the publish capabilities)
GCP: FCM

The difference with using one of these services to a WS implementation is that the services generally only do server->client data push, so requests to subscribe/unsubscribe and the rest of your GraphQL queries & mutations etc still need to be through a HTTP GraphQL server - personally I like this unidirectional flow of data anyway.

Recently in the GraphQL Radio podcast, ep3 Microsoft guest Erik Schlegel outlined how they are using Azure Event Hub as the data transport for their GraphQL subscriptions - https://youtu.be/crXSN8SKjGI?t=14m58s It is also mentioned that they may be open-sourcing their Azure Event Hub / PubSub Engine wrapper at a later date.

Another issue with this type of system is that the message payload sizes are then dictated by the service being used, which vary from vendor to vendor. GCP Firebase Cloud Messaging is what I am working on atm as I use GCP more than AWS.

[Siyfion]

@jthegedus ahh, I see where you're going with this now. So basically someone just needs to write a subscription transport-layer for SNS/FCM/Event Hub (or all three) and then use that for the subscription updates. Interesting!

If only I had a bit more time spare I'd take a look myself... maybe in a few weeks.

[jthegedus]

@Siyfion Precisely, I just happened to start looking into this when significant changes were being made. I'm now just waiting for this to be merged #78 which I think is the last significant change of the subscription related layer at this time.

I'm going to work on the FCM transport layer, I believe some Microsoft developers will publish the Event Hub implementation sometime in the near future. As for AWS I'm not as proficient there, so maybe someone else can tackle that package.

[Siyfion]

@jthegedus Awesome, it almost sounds like a plan taking shape! lol.

As for the AWS-side, I would imagine it's probably the more commonly used cloud provider, so I'm sure there will be some people around that are happy to help, maybe even some of the MDG guys that helped implement the Galaxy hosting solution, I imagine they are pretty familiar with the AWS stack..?

[jthegedus]

Some resources I've found regarding possible implementations using AWS. These don't use GraphQL, but show how a messaging service can be created on AWS services:

AWS IOT: https://serverless.com/blog/serverless-notifications-on-aws/ @mattfysh
AWS SQS + Cognito: https://serverless.com/blog/how-reuters-replaced-websockets-with-amazon-cognito-and-sqs/ and this https://github.com/ReutersMedia/sqs-browser-events

The interesting thing about a serverless backend is that it changes which problems need solving. Instead of scaling connection etc you need to consider the limitations of the individual services. Eg: payload size, payload TTL, delivery guarantees (at least once and dealing with duplicate deliveries), upstream messaging etc

[jonmanzo]

I have this working in AWS using the demo from medium. Once I have in incorporated into the project it was poc'd for I'll try and write it up here, but in the meantime: You can't use SNS as it is not a traditional pubsub broker. Have to implement using graphql-mqtt-subscriptions, AWS IOT & the aws iot js sdk