Preface
Since I kind of opened this discussion a few days ago, in this thread [Chrome Extension] Supabase Live and Staging I actually found a really neat way of doing this, at least while WeWeb rolls out their own solution.
This solution also doesn’t account for the part where WeWeb uses the Private - Secret keys to fetch things like fetching the users etc. What does this work on?
- Fetching the tables within your collections creating process a.k.a it can introspect your DB’s schema
- Changing the auth endpoint, so you can authenticate with the users from your other instance, e.g. localhost
- Mocking / redirecting the request towards our localhost, or our any other Supabase instance
Disclaimer
I don’t encourage you guys to paste any sensitive API keys anywhere, especially the Private API keys in this case of Supabase. In this “tutorial” I’m gonna be using only the Public API key, so that we can set up the Supabase properly.
Prerequisites
- First of all, you’ll need the Requestly - Extension for Chrome. The team behind this extension is amazing, big kudos to them, they actually fixed an issue so I could make this work with Supabase in a matter of days. - The free plan should be enough, as our setup is very minimal, but I strongly encourage you support them, as they made this possible.
- You’ll need your second instance or a self-hosted instance as shown by @flo in a tutorial, more resources about the self-hosting at the end - in the
References
section - You’ll need a WeWeb App set up with the Supabase plugin, on your “production” instance
How it works
The process itself is very simple, we’re gonna be intercepting and modifying the requests that WeWeb does to Supabase, for this we’ll need to gather a few things first. For clarity I will be using Staging
and Production
to identify our two Supabase Instances.
We’ll need to get the following things from our Supabase Dashboard:
- The
Production
instance’s URL, this also can be found in WeWeb plugin’s setup, or you can get this via the Network tab in your browser. - From the
Staging
instance, we’re gonna be getting the Public URL and Public API key. I repeat, in the ideal case please, use the Public key.
After this we head to the Requestly Extension and set up the following rules via the drop-down:
We modify the Public URL first
With this rule we’ll be intercepting the WeWeb’s calls with your Production’s URL and we’ll be replacing the URL part to match our Staging URL. For this we apply the setup shown in the screenshot while using the Requestly’s Replace String
rule.
We alter the <apikey>
headers to match our Public URL
With this rule we’ll be intercepting the WeWeb’s calls with your fresh new Staging URL that we replaced and we’ll be replacing request’s Headers with our Staging’s URL in order to match the two. For this we’ll use the Requestly’s Modify headers
rule.
And that’s it! Simple as that, you now can refresh your page and switch on and off the rules at your pleasing. This will allow you to do many things, such as testing your Staging changes within the Editor etc.
If you go beyond “trying out and testing the modified tables/endpoints” I highly suggest creating a folder within WeWeb to separate the “Staging” collections/workflows/whatever you do from your Production stuff, to avoid mess.
Big thanks to the Requestly guys
I can’t praise these new found friends more, they worked on some issues that their extension had with me in a super short timeline and eventually worked it out supafast, making this tutorial possible. I definitely strongly suggest supporting them.
Closing words
I hope this helps at least some people to make their workflow a little more pleasurable while we are waiting for a proper implementation from WeWeb’s side. If anyone struggles, or needs some help, and this goes for anything, not just Supabase, feel free to message me, drop a comment here, or eventually check out the little link I have in my bio, where I do 1:1 sessions with aspiring no-coders