mirror of
https://github.com/supabase/supabase.git
synced 2026-09-29 22:42:58 +08:00
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## Problem The Docs E2E link checker found broken links throughout docs, starting with `phone-login.mdx` pointing to `/docs/guides/cli/config` (404). Old links like `/docs/guides/cli/config` still work on the live site because `supabase.com` has redirects set up for them, but these links break on the docs preview site, which is what the E2E check tests against. These issues look clean on the live site, and I didn't catch them in my first pass because I was testing production instead of the preview. The E2E check only tests the ~20 pages a given PR happens to touch, so fixing the pages it flagged kept exposing more of the same problem one page at a time as each fix pulled in a new file. To stop chasing this incrementally, I cross-referenced every `/docs/guides/*` and `/docs/reference/*` redirect source in `apps/www/lib/redirects.js` against actual usage across all of `apps/docs`, and verified each candidate against the live preview. ## Solution Rather than updating the Docs E2E link checker, this PR resolves the links. **Why:** we own these docs, so keeping the links clean without redirects is keeping the house maintained. See [Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/). Updated every link still using an old path to point straight at the current page instead of relying on a redirect. This covers old links like: - `/docs/guides/cli/config` → `/docs/guides/local-development/cli/config` - `/docs/guides/cli/getting-started` → `/docs/guides/local-development/cli/getting-started` - `/docs/guides/cli/local-development` → `/docs/guides/local-development/database-migrations` - `/docs/guides/cli/managing-environments` → `/docs/guides/deployment/managing-environments` - `/docs/guides/cli/seeding-your-database` → `/docs/guides/local-development/seeding-your-database` - bare `/docs/guides/cli` → `/docs/guides/local-development` - `/docs/guides/platform/compute-add-ons` → `/docs/guides/platform/compute-and-disk` - `/docs/guides/platform/shared-responsibility-model` → `/docs/guides/deployment/shared-responsibility-model` - `/docs/guides/database` → `/docs/guides/database/overview` - `/docs/reference/javascript`, `/docs/reference/dart`, `/docs/reference/kotlin`, `/docs/reference/python`, `/docs/reference/csharp` → their `/introduction` pages (the redirect's own destination, `/start`, turned out to be dead even on production — a separate bug in `redirects.js` I didn't touch here) - and about 35 more of the same pattern, listed in the commit messages Also fixed a handful of dead heading anchors found along the way (links that resolve to the right page but point at a `#section` that got renamed or moved), including the original `#bigquery` anchor and a few in `connecting-to-postgres.mdx` where content moved to its own dedicated page. Left alone on purpose: - `content/guides/cli.mdx` — this page has no route in the docs app at all (no `app/guides/cli/` directory), so it 404s even in production before the `www` redirect ever fires. Fixing its internal link wouldn't change that; it needs an actual routing/content decision, not a link fix. - A few candidates that already resolve fine as-is (`pg_partman`, bare `/docs/reference/api`, bare `/docs/reference/cli`) — confirmed via curl, left untouched. ## Manual testing 1. Confirmed every new link target actually exists by checking the destination file/page and matching heading anchors. 2. Cross-referenced every `/docs/guides/*` and `/docs/reference/*` redirect source in `apps/www/lib/redirects.js` against real usage in `apps/docs`, and curl-verified each old path (404) and new path (200) against the live PR preview before fixing it. 3. Ran the Docs E2E link checker locally against changed pages. 4. Spot-checked the original broken link from CI (`/docs/guides/cli/config`) to confirm it now points to a working page.
266 lines
8.2 KiB
Plaintext
266 lines
8.2 KiB
Plaintext
---
|
|
id: 'functions-quickstart'
|
|
title: 'Getting Started with Edge Functions'
|
|
description: 'Get started with Supabase Edge Functions.'
|
|
subtitle: 'Learn how to create, test, and deploy your first Edge Function using the Supabase CLI.'
|
|
---
|
|
|
|
This guide walks you through creating, testing locally, deploying, and invoking a Supabase Edge Function using the CLI. By the end, you'll have a working function running on Supabase's global edge network.
|
|
|
|
You can also create and deploy functions directly from the Supabase Dashboard. Read [the Dashboard Quickstart guide](/docs/guides/functions/quickstart-dashboard) for more information.
|
|
|
|
<Admonition type="note">
|
|
|
|
Supabase Edge Functions **only** supports creating functions in TypeScript with [the Deno runtime](https://deno.com/). This is because Deno was designed with extensibility in mind and its Rust codebase offers a modern developer experience, memory safety, and other features ideal for running edge functions.
|
|
|
|
</Admonition>
|
|
|
|
## Prerequisites
|
|
|
|
- Make sure you have the Supabase CLI installed and configured. Read [the CLI installation guide](/docs/guides/local-development) for installation methods and troubleshooting.
|
|
- Running and testing Supabase Edge Functions locally requires [Docker](https://www.docker.com/) or a Docker-compatible runtime.
|
|
|
|
## Step 1: Create or configure your project
|
|
|
|
If you don't have a project yet, initialize a new Supabase project in your current directory.
|
|
|
|
```bash
|
|
mkdir my-edge-functions-project
|
|
cd my-edge-functions-project
|
|
supabase init
|
|
```
|
|
|
|
If you already have a project locally, navigate to your project directory. If you haven't configured the project for Supabase yet, make sure to run the `supabase init` command.
|
|
|
|
```bash
|
|
cd your-existing-project
|
|
supabase init # Initialize Supabase, if you haven't already
|
|
```
|
|
|
|
<Admonition type="note">
|
|
|
|
After this step, you should have a project directory with a `supabase` folder containing a `config.toml` file.
|
|
|
|
</Admonition>
|
|
|
|
## Step 2: Create your first function
|
|
|
|
Within your project, generate a new Edge Function with a basic template:
|
|
|
|
```bash
|
|
supabase functions new hello-world
|
|
```
|
|
|
|
{/* TODO: Link to parameter documentation */}
|
|
|
|
<Admonition type="note" title="Secure your function with Supabase Auth">
|
|
|
|
When an HTTP request is sent to Edge Functions, you can use Supabase Auth to secure endpoints. By default, the `supabase functions new` command adds handling a valid publishable or secret key to the basic template. However, you can change this behavior with the `--auth` flag when creating a new function.
|
|
|
|
</Admonition>
|
|
|
|
This creates a new function at `supabase/functions/hello-world/index.ts` with this starter code:
|
|
|
|
```tsx
|
|
export default {
|
|
fetch: withSupabase({ auth: ['publishable', 'secret'] }, async (req, ctx) => {
|
|
const { name } = await req.json()
|
|
|
|
return Response.json({
|
|
message: `Hello ${name}!`,
|
|
})
|
|
}),
|
|
}
|
|
```
|
|
|
|
This function accepts a JSON payload with a `name` field and returns a greeting message.
|
|
|
|
<Admonition type="note">
|
|
|
|
The `supabase functions new` command also optionally creates Deno configuration for VSCode.
|
|
|
|
</Admonition>
|
|
|
|
## Step 3: Test your function locally
|
|
|
|
After starting Docker, start the local development server to test your function:
|
|
|
|
```bash
|
|
supabase start # Start all Supabase services
|
|
supabase functions serve hello-world
|
|
```
|
|
|
|
On first use, the `supabase start` command downloads Docker images, and starts all Supabase services locally, which can take a few minutes.
|
|
|
|
Your function is now running at [`http://localhost:54321/functions/v1/hello-world`](http://localhost:54321/functions/v1/hello-world). Hot reloading is enabled, which means that the server automatically reloads when you save changes to your function code. Keep this terminal window open.
|
|
|
|
### Function not starting locally?
|
|
|
|
- Make sure Docker is running
|
|
- Run `supabase stop` then `supabase start` to restart services
|
|
|
|
### Port already in use?
|
|
|
|
- Check what's running with `supabase status`
|
|
- Stop other Supabase instances with `supabase stop`
|
|
|
|
## Step 4: Send a test request
|
|
|
|
Open a new terminal and test your function with curl. You can find your local Publishable key, by running `supabase status`, or you can find the complete `curl` command already in `functions/hello-world/index.ts`.
|
|
|
|
```bash
|
|
curl -i --location --request POST 'http://127.0.0.1:54321/functions/v1/hello-world' \
|
|
--header 'apiKey: <SUPABASE_PUBLISHABLE_KEY>' \
|
|
--data '{"name":"Functions"}'
|
|
```
|
|
|
|
After running this curl command, you should see:
|
|
|
|
```json
|
|
{ "message": "Hello Functions!" }
|
|
```
|
|
|
|
You can also try different inputs. Change `"Functions"` to `"World"` in the curl command and run it again to see the response change.
|
|
|
|
<Admonition type="note">
|
|
|
|
After this step, you should have successfully tested your Edge Function locally and received a JSON response with your greeting message.
|
|
|
|
</Admonition>
|
|
|
|
## Step 5: Connect to your Supabase project
|
|
|
|
To deploy your function globally, you need to connect your local project to a Supabase project.
|
|
|
|
<Admonition type="note" title="Need to create a new Supabase project?">
|
|
|
|
Create one at [database.new](https://database.new/).
|
|
|
|
</Admonition>
|
|
|
|
First, login to the CLI if you haven't already, and authenticate with Supabase. This opens your browser to authenticate with Supabase; complete the login process in your browser.
|
|
|
|
```bash
|
|
supabase login
|
|
```
|
|
|
|
Next, list your Supabase projects to find your project ID:
|
|
|
|
```bash
|
|
supabase projects list
|
|
```
|
|
|
|
Next, copy your project ID from the output, then connect your local project to your remote Supabase project. Replace `YOUR_PROJECT_ID` with the ID from the previous step.
|
|
|
|
```bash
|
|
supabase link --project-ref [YOUR_PROJECT_ID]
|
|
```
|
|
|
|
<Admonition type="note">
|
|
|
|
After this step, you should have your local project authenticated and linked to your remote Supabase project. You can verify this by running `supabase status`.
|
|
|
|
</Admonition>
|
|
|
|
## Step 6: Deploy to production
|
|
|
|
Deploy your function to Supabase's global edge network:
|
|
|
|
```bash
|
|
supabase functions deploy hello-world
|
|
```
|
|
|
|
If you want to deploy all functions, run the `deploy` command without specifying a function name:
|
|
|
|
```bash
|
|
supabase functions deploy
|
|
```
|
|
|
|
<Admonition type="note" title="Docker not required">
|
|
|
|
The CLI automatically falls back to API-based deployment if Docker isn't available. You can also explicitly use API deployment with the `--use-api` flag:
|
|
|
|
```bash
|
|
supabase functions deploy hello-world --use-api
|
|
```
|
|
|
|
</Admonition>
|
|
|
|
When the deployment is successful, your function is automatically distributed to edge locations worldwide.
|
|
|
|
<Admonition type="note">
|
|
|
|
Now, you should have your Edge Function deployed and running globally at `https://[YOUR_PROJECT_ID].supabase.co/functions/v1/hello-world`.
|
|
|
|
</Admonition>
|
|
|
|
## Step 7: Test your live function
|
|
|
|
🎉 Your function is now live! Test it with your project's publishable key that you can find in the **Settings > API Keys** section of the [Dashboard](/dashboard/project/_/settings/api-keys):
|
|
|
|
```bash
|
|
curl --request POST 'https://[YOUR_PROJECT_ID].supabase.co/functions/v1/hello-world' \
|
|
--header 'apikey: <SUPABASE_PUBLISHABLE_KEY>' \
|
|
--header 'Content-Type: application/json' \
|
|
--data '{"name":"Production"}'
|
|
```
|
|
|
|
**Expected response:**
|
|
|
|
```json
|
|
{ "message": "Hello Production!" }
|
|
```
|
|
|
|
## Usage
|
|
|
|
Now that your function is deployed, you can invoke it from within an app:
|
|
|
|
<Admonition type="note" label="Calling from the browser?">
|
|
|
|
Make sure your function can handle [CORS](/docs/guides/functions/cors) (Cross-Origin Resource Sharing) requests by configuring its headers correctly.
|
|
|
|
</Admonition>
|
|
|
|
<Tabs
|
|
scrollable
|
|
size="small"
|
|
type="underlined"
|
|
defaultActiveId="supabase-js"
|
|
>
|
|
|
|
<TabPanel id="supabase-js" label="Supabase Client">
|
|
|
|
```jsx
|
|
import { createClient } from '@supabase/supabase-js'
|
|
|
|
const supabase = createClient('https://[YOUR_PROJECT_ID].supabase.co', 'YOUR_PUBLISHABLE_KEY')
|
|
|
|
const { data, error } = await supabase.functions.invoke('hello-world', {
|
|
body: { name: 'JavaScript' },
|
|
})
|
|
|
|
console.log(data) // { message: "Hello JavaScript!" }
|
|
```
|
|
|
|
</TabPanel>
|
|
|
|
<TabPanel id="fetch" label="Fetch API">
|
|
|
|
```jsx
|
|
const response = await fetch('https://[YOUR_PROJECT_ID].supabase.co/functions/v1/hello-world', {
|
|
method: 'POST',
|
|
headers: {
|
|
apikey: '<SUPABASE_PUBLISHABLE_KEY>',
|
|
'Content-Type': 'application/json',
|
|
},
|
|
body: JSON.stringify({ name: 'Fetch' }),
|
|
})
|
|
|
|
const data = await response.json()
|
|
console.log(data)
|
|
```
|
|
|
|
</TabPanel>
|
|
|
|
</Tabs>
|