Curious what approaches one could take to implement realtime functionality (think: notifications, chat apps, etc).
When you own the server, I’d typically spin up websocket connections, but I’m not sure how to do that with custom lambda functions given they were stateless.
Is there a way to accomplish this?
Hi there @tconroy! Thanks for joining the forums.
There are a few moving pieces when it comes to Subscriptions, which haven’t yet been integrated to the best of my knowledge. Most people are starting with Polling. @rob you seen any good Polling examples in the Issues or Forum topics yet? I couldn’t find anything at a quick glance.
Back to Subscriptions, here’s a comment where I outlined the pieces. Right now, if you deploy to Netlify, you won’t have access to additional AWS tools you’d need. But if you configured your own deploy to AWS directly… 
I haven’t seen any polling stuff yet, no. But I have used a setInterval() in a useEffect() before…you could use that to constantly hit an endpoint and then update state when something changes. I’m not sure how web sockets are going to work in the Jamstack environment since the lambda won’t run forever. Are there any WSaaS providers yet? 
I’m not sure how web sockets are going to work in the Jamstack environment since the lambda won’t run forever.
Here’s the (purported) AWS solution for their own AWS Lambda problem re websockets:
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.
@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
@dcsan Welcome to the Redwood community! 
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 
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.
@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.
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
It was just brought to my attention that we also have a cookbook recipe on the topic
Just to summarize a few things already stated by others here:
worth it. And the community here would 
helping you out along the wayHi @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 .
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…
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
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 
No magic. It’s an Express server that respects the Redwood Functions dir conventions. Here’s the package code:
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
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.
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.