[Supabase] Switch between Production and Staging in one click

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

  1. 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.
  2. 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
  3. 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:

  1. 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.
  2. 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 :slight_smile:

References

5 Likes

Very cool! Thanks so much for taking the time to put this together @Broberto, appreciate it! :slight_smile:

1 Like

Just 1 tiny tip, put both the rules in a collection to manage active/inactive status with 1 click. Every click matters :slight_smile: .

1 Like

Hey! Good tip :slight_smile: I didn’t look into this that deeper, as it seems like they are “depending” on each other. So if I disable the main one (e.g the Public URL one) the depending one (apikey) never fires. But definitely, your tip is more bulletproof :muscle: Thanks!

1 Like

You are right, the Replace rule is the main rule. I liked how you described using collections as “bulletproof” — it’s a great metaphor! :blush:

One edge case I was considering is that the header rule can sometimes interfere with staging calls, but of course, this highly depends on the particular use case and setup. Just a general observation. :+1:

1 Like

Many thanks for this! This works perfectly for me in the editor, but not in staging. Any ideas what might cause that? I can authenticate successfully but my fetch requests do not return any data. I can fetch data without issue when I duplicate the requests in Postman.

1 Like

Hello, I’m glad it works. I’d need to see the network tab, and get to know your staging/prod to indentify them, and eventually understand the issue though. My best guess is that you could find answers in the Console and Network tabs.