For folks building CRUD apps I think Redwood hits the nail right on the head with serverless GraphQL API support being so easy. However for apps with a realtime component, which I think are increasingly common, and something node.js devs tend to be accustomed to having, it’d be great if Redwood had a story for pubsub and websocket connection serving.
Prior art would include django-channels, Rails’ ActionCable, Phoenix’s Channels, etc.
I think there’s a few considerations that are likely deep questions for the core team that my lowly forum post can’t answer like:
- can websockets be the transport that supports GraphQL (and GraphQL subscriptions when that’s a thing)
- how do you deploy long lived, connection-stateful websocket servers on serverless platforms
- how deep would Redwood’s integration go, from “none at all, use something else” to “we have a built in backend-configurable pub-sub bus that can automatically power GraphQL subscriptions and automatically syndicate backend data changes”
I have a small immediate need for websocket stuff to power user presence indicators on a page but I think it won’t be too hard to just do something outside the Redwood app for that. Just wanted to log a vote for support someday!
2 Likes
Interested in this as well. To date, I don’t know if this has come up much yet aside from one GitHub Issue asking if Subscriptions were supported by Prisma. (Nope, cause all the action is in the GraphQL provider.)
We use Apollo GraphQL, which supports Subscriptions. So the trick will be the Lambda/Websocket/PubSub, which I know nothing about. I did a little research and found there’s been positive progress for these in the last year. There’s a long thread with a key comment here: https://github.com/apollographql/apollo-server/issues/2129
Links here:
We can check with the Netlify team, but it’s unclear if they are capable of using AWS API Gateway for Subscriptions. But it is mentioned in this doc:
I also didn’t look deep enough to understand if the API Gateway fulfills the production PubSub requirements.
What is most likely possible in the near term is you’d need to configure your own deploy to AWS Lambdas. It’s definitely possible with the right config. And we are working on ways to make build tooling flexible and deploy config easier.
Supporting this in Redwood would be great for the framework and the community. If you want to try and make it happen by leading the way, we’ll definitely support you as best we can. Maybe create a public repo project with a simple use-case, and we’ll work with you to deploy?
Let me know your thoughts and what you’d be up for + interested in.
1 Like