Building Supabase Serverless Workflows with Cloudflare Workers

Kristian Freeman: [0:00] There may be certain situations where you want to interact with the Supabase database in a asynchronous way, for instance, background tasks, or scheduled tasks that you might want to have happen outside of your user interface.

[0:12] One great way to handle this is by using Cloudflare Workers to build a serverless API that works with Supabase. This code base, which is linked to the course here on Egghead, is signalnerve/supabase-workers-proxy which you can use as a proof of concept for making API request to Supabase from inside of Cloudflare Workers.

[0:31] To try out this code base, I'll just run git clone with this URL Supabase workers proxy, and I'll just give it a name like Supabase Workers Example.

[0:42] If I look inside of the code here and index.js, there's a couple things going on here that I won't go into super huge detail about, but I'll tell you a little bit about the simple aspects of it which is first creating a client. This is a lot like what we did when we made a browser-facing client for Supabase.

[0:58] We say createClient with a Supabase URL and an API key. Then further down, we have these different routes, so router.get/users, which will make a request to Supabase for, say, a user, or a user based on an ID or all kinds of other things.

[1:14] You can make requests directly inside of the serverless function and work with your Supabase data outside of a front-end application. To deploy this, I'm just going to open up the terminal.

[1:25] First, I'm going to run npm install. Then, I'm also going to fill in my regular terminal here. This will have a type of web pack, and then your account ID, which is already filled in for me because this is my project. If you run wrangler whoami, you can see that there are different account IDs that will show up here that will match your specific account.

[1:45] Pick the one that you want to deploy your workers project to. In this case, I'm just going to deploy to workers dev. That'll be fine for me. Though, if you want to deploy this to a custom domain or something like that, you can fill in the route and zone ID, and set workers dev to false.

[1:59] First, I'll run wrangler publish to just deploy my application. Once it's published, I won't be able to use it quite yet, because I need to fill in the Supabase URL and Supabase API key.

[2:11] There are two different ways to do this. The first is using the anon or public key. This is the same key that we've been using in the browser. Again, in the future, obviously, it's recommended that you enable what they call row-level security, and set up policies that say for instance, what tables, what rows and what columns can be updated from the browser.

[2:31] Here you can also use the service role, which is a secret that allows you basically admin-level access to edit anything inside of your project. Because this isn't in the browser, and because it's deployed at a serverless function level, you can safely use this key and in fact we'll use a wrangler secret for it, which will allow it be encrypted and be safe to use to this row-level administrative tasks.

[2:57] Let's start by copying the URL here and back in the terminal over on wrangler secret put, and then give the name Supabase_URL. I will paste in my Supabase URL here which will set the secret Supabse URL which will be used here to match this URL that I pasted into the terminal.

[3:19] The other key here is the service role. If I ran wrangler secret put SUPABASE_API_KEY, I can then paste in this key which I'll do off screen because it is secret. That will set this SUPABASE_API_KEY to be your service row-level API key.

[3:37] Once I've done that I'll be able to look at my serverless function inside of my browser. I'll go to Supabase workers example.signalnerve.workers.dev and I'll go to /rayback with one user here which is my ID, fc8bo, etc. That's the one we've used throughout this example and then my username which is currently set to Kristian123.

[4:01] Unfortunately, real time subscriptions and things like that aren't covered inside of this because it is a very simple REST API. For instance, if I come here and change my username to something like Kristian and save it, it updates here in the UI but of course it won't update here. This is a static response that is just getting sent back from this REST API.

[4:22] If I refresh, it will be up to date anytime they make a request. This can be for things like analytics or pooling data or even sending updates from a serverless function, on a schedule or in some background task to your database without having to have it happen inside of your front end UI.