I struggled with this for a while but finally got Supabase Realtime to work and the setup was not straightforward. There are some unlabeled restrictions on WeWeb’s implementation you must work around.
First, WeWeb results in unpredictable things if you try to enable Realtime on a Collection you have setup in the “advanced” mode (which creates joins between tables in Supabase behind the scenes).
When I set up realtime (according to the WeWeb docs) with on two collections like this, item deletes would be realtime but item inserts would not be…even though they were setup the same.
After some back and forth, WeWeb support suggested the proper setup was to change the page design from using a collection-based approach to one using variables for all of the data on the page. So instead of this (using the blue collection data sources):
You use this (green variable data sources):
and you set those variables via an ‘on page load’ workflow:
This was actually much less involved than I thought: since the existing collections are just being set to the new variables on page load, the new variables are direct drop ins for the previous collection ones anywhere on the page.
You also need a way to have user ‘subscribe’ to the realtime “channels” monitoring your database changes. There is not a way to monitor a user’s ‘subscription status’ (that I’ve found anyway), so I just added another ‘on page load’ workflow that subscribes any user visiting this page to the two channels used, one for each database tables this page makes changes to.
Note: you must configure your table to be ‘realtime’ in Supabase and weweb:
(I actually don’t know if/think you must enable realtime on the collection in WeWeb when using this, variable-based configuration, but I already had it setup)
Now the magic step that actually enables realtime to happen. For this you need an app workflow, something I had never used before and is a little hidden in the WeWeb editor:
An app workflow is just a normal workflow, but it runs across all your pages. In my case, I do have a couple other app pages that can add or remove data to my realtime tables, so using an app-level workflow ensures even when one user on page X makes a database entry, a second user on page Y sees it instantly.
You need a workflow that looks similar to this:
At the top you see the “realtime database changes” event and the channel name. That flows into a splitter that separates the various database actions, as each needs to change the data variables (the replacements for our on-page collection data) using slightly different formulas.
Note: I use a “return a value” event at the top because it is easier to setup the ‘change variable value’ steps used later to reference that. Otherwise your realtime events do not get stored after they occur…and building formulas using that data becomes difficult!
Here is the logic of the splitter:
Here is the logic of the “insert”:
Note that the data variable I’m using on the front end to replace a collection is called “Calendar Variable Test-B” and it is of type ‘array’. Because of how my data is structured (and how my page was already built and configured to reference that data), I am building an ‘object’ in a specific format from the realtime response data. This will entirely depend on your data and needs.
But you will need to “update array” with an ‘insert at end’ of your data to ensure the page actually updates in realtime.
Here is my ‘delete’ logic, which uses ‘findindexbykey’ to remove the correct item from the data variable array. I’ve expanded “Action 2” here so you can see the value of adding that ‘return a value’ step. If you didn’t have this, you wouldn’t be able to specify the “Event data.results.data.old.id” (the ID of the item we are trying to remove) in the formula.
The ‘update’ logic is just a combination of the other two: the ‘findindexbykey’ from the delete with the ‘createobject’ of the insert, so I will not show it again. Just chose “update one item” from the ‘change variable value’ step.
I think that’s it! If I remember something else I’ll amend this post, but with this setup the front-end of my app instantly responds to changes made in the relevant tables in the database, across different users on different pages!
My use-case has two different tables that impact the same front-end page, so I just duplicated the setup (mainly by adding a second app-level workflow) for a second data variable. Could probably be merged into one workflow, but it was easier to test it separately.
Footnote.
I want to thank WeWeb support for helping me figure this out, especially Daniel, who chatted with me a bit and pointed me in the right direction. I certainly would not have solved this without that direction.
However, I also want to encourage WeWeb to reconsider the experience their support setup provides. At least for my experience, the support was chat-based and largely built around real-time interaction, which made it tough to make progress unless I was both already working in the system and able to stop what I was doing and respond to replies instantly. I’m grateful for the ability to receive support, but I hope someone is at least keeping the support experience in mind as you keep growing!
