How would you implement realtime / websockets in RedwoodJS?

Get Help and Help Others
5

I am starting an app that will have a chat component, and really interested in Redwood, but wonder how much I can hook into things for realtime messaging.

above mentions polling but I’m wondering how to provide long-polling, eg streaming to an http connection, rather than just continually hitting the server? Can I provide endpoints that are plain express like endpoints in a redwood app?

Using redwood can I use graphQL subscriptions?
Apollo supports it and as ex-meteor guys they really did this well imho. Wonder how that works with current redwood setup.

Can I add non-redwood API endpoints? I assume could i connect on the server side directly to postgres and make my own client/server socket feature?

How tied is redwood to serverless?
If i just want to deploy on my own infra, to avoid all the problems with sockets on lambda, is that going to be swimming upstream?
I could not find anything on the deploy docs about running redwood on my own more bare-metal server.

Sorry if some of these are basic questions, I’m experienced with realtime apps but not with redwood much yet.

1 Like
6

@dcsan https://getstream.io/chat/ Is really good

It would be all client side for the real-time sockets.

You could integrate api side to manage users and channels etc

7

@dcsan Welcome to the Redwood community! :wave:

I have a Redwood chat example using Supabase here: https://github.com/Tobbe/supaslack

Redwood does not support GraphQL Subscriptions (yet), so unfortunately you can’t leverage that.

Redwood can 100% run on your own hardware. @viperfx is doing that. But I don’t think we have a complete write up on how to do it yet. There has been some talk here: Serverfull hosting

We would for sure want to make Redwood’s realtime story more solid, so we’re super happy to have you here with your experience in the area. If you have any concrete ideas on how we can improve, don’t hesitate to let us know :bulb:

2 Likes
8

thanks! getstream looks decent, but it goes from free trial to $499/month.
My initial app is also an admin dashboard for Discord bots, so I don’t really want another server side API in the mix…
I’ve used stuff like pusher before but always have problems with custom/extended payloads, so prefer to roll my own.

2 Likes
9

@Tobbe thanks for the nice community welcome and POC link.

I checked your supabase POC and if I’m correct your integration is fully on the client side?
eg the custom Store here
So then if self-hosting I would stand up a fully separate supabase server to deal with the sockets traffic?
I worry that makes integrations for auth or shared User tables more work. And also I need to worry about deploying two different envs if there is code related to socket logic server side.
Or did I misunderstand? I couldn’t see much code server side apart from some auth

Well I guess, given all the dependencies on cloud and serverless, it seems Feathers is still a more optimal stack for shipping/deploying a realtime app quickly but redwood sure looks nice.

10

Yes, all the real time stuff is client side with websockets.

Well, depends if you just want to self-host Redwood or Redwood + DB. Easiest would absolutely be to self-host Redwood, and then just use the (free) supabase provided postgresql db. That’ll give you a DB both for the real-time stuff and for auth+user table

11

It was just brought to my attention that we also have a cookbook recipe on the topic

12

Just to summarize a few things already stated by others here:

  • The current serverless architecture landscape is the problem – it is, ironically, lacking support for Subscriptions. It’s not about Redwood. Even if you deploy directly to AWS Lambdas and try to use the AWS API Gateway for Subscriptions capability, I’ve heard it’s just terrible.
  • You should definitely just self-host Redwood and skip the serverless infrastructure (see doc above). @Chris is self-hosting Everfund on Digital Ocean. @peterp and @danny are using Render.com You could use AWS EC2 or whatever.
  • Redwood is :100:worth it. And the community here would :heart:helping you out along the way
13

Hi @tconroy , I didn’t test this solution yet but I think Pusher can be a good way to add realtime functionality to serverless (and RedwoodJS) They write a quick example about it .

2 Likes
14

if we’re using pusher or pubnub (or firebase) to do the realtime part, it means lashing more things together = complexity, auth problems etc.
Also FWIW all those services are blocked or really slow in some places like China, one reason I personally wanted a self-hosted solution. Great for scaling up in the west though…

1 Like
15

This approach of hosting a redwood app without cloud serverless, is it effectively running a mini “functions” gateway internally? I’m wondering how much this is fighting what redwood was designed for, if more magic is being added on top or taken away.

There seem to be some drawbacks eg why would this be the case:

Caveat: the API seems to only work in fork mode in PM2, not cluster mode

1 Like
16

That’s interesting. You don’t mean self-hosting supabase, just using it’s postgres DB like a 3rd party postgres host? I’m not sure they’re that keen on that use case or provide the raw pg login, i would think they want to focus on apps that go through their api or client library.

I checked their realtime example which is an elixir app, they’re using the replication log to listen into DB changes, similar to how meteor used to listen to mongodb for the realtime subscriptions.

There is some talk of a docker container for supabase but it’s not there yet. That would enable Redwood to just use the postgres db directly with no rewrites for DB driver. That sounds like the way to go and would add an instant realtime layer to redwood, as well as the cool DB admin features supabase provides - I’ve heard redwood team talk wistfully about the good old days of phpMyAdmin :blush:

17

No magic. It’s an Express server that respects the Redwood Functions dir conventions. Here’s the package code:

18

Yes, exactly like that! I do that here, in my “Experiment 1” Supabase redwood experiments

If you sign in to Supabase and go to Settings → Database they give you the info you need to connect straight to the DB

image
image780×144 8.89 KB

19

Just wanted to chime in on this one because I too was looking for some WebSockets action on my current project. I really didn’t want to do all the setup with a custom server. I currently like netlify and the simplicity, and really didn’t want to do polling. So I decided to give supabase a shot and after some googling DLed my current postgres database off of Heroku and was able to populate my supabase with all of the rows that were in heroku. Then all I had to do was change the database_url in the .env to my supabase database and setup this little bit of frontend code

import { createClient } from '@supabase/supabase-js'

const supabaseUrl = 'https://***.supabase.co'
const supabaseKey = process.env.SUPABASE_KEY
const supabase = createClient(supabaseUrl, supabaseKey)

const mysubscription = supabase
  .from('Channel')
  .on('UPDATE', (payload) => {
    console.log('Change received!', payload)
  })
  .subscribe()

and anytime my data changes I can receive the updates directly to my frontend. This has been a huge time saver and has been sufficient enough for my small app. If others need this kind of functionality I would recommend checking it out.

7 Likes
20

Hey Tobbe your supabase chat app looks pretty cool , but getting a bit lost on trying to replicate that on our end.

I understand you are likely busy but if it’s at all possible perhaps you could write some tutorials regarding these.

As it is finding tutorial for redwood is actually hard , not many out there ; and given your knowledge if you have some time , tutorials from you would be really helpful.

1 Like
21

You’re making me blush here with all the flattery :blush:

With Redwood 0.22.0 we got Supabase 1.0 support, and I’ve been wanting to update my supaslack example. This could just have been the kick in the behind I needed to start working on that. No promises, but ping me again middle of next week if you haven’t heard anything from me.

3 Likes
22

I love RedwoodJS and try to use it for each new project.

I’ve tried to port https://video.sebastienbiollo.com (see GitHub - 0x5eba/Video-Meeting: Google Meet / Zoom clone in a few lines of code) over to RedwoodJS but then was getting stuck with how to build the equivalent of these 100 lines (single-file backend Express server) to set up socket.io on RedwoodJS for group video chat.

It seems like a video chat app is not suited to a serverless architecture and is a case (like others have mentioned above) where I ought to go a different direction.

Is my understanding correct, or has anything changed since these earlier posts? Thank you so much. :slight_smile:

23

Hey Ryan, you’re correct that we have not worked out any serverless-native solutions for WebSockets. To bang my own drum for a second, Cloudflare Workers recently added support for WebSockets which would be a nice add-on to the benefits we already would get from running RedwoodJS on Cloudflare’s edge network with Workers. This is still in the early research stage unless anyone with more Workers experience wants to run with it.

Until that is worked out you’ll either want to go the self-hosted route, which we’re also working on making a lot easier by containerizing Redwood, or check out the Supabase solutions already mentioned. Render may also have some WebSockets ability but you’d have to ask someone with more Render experience than me.

24

Not 100% related to realtime/subscriptions, but for practical purposes there is an easy way to do polling as a workaround: Cookbook example: Polling - #9 by dthyresson