@@ -50,57 +81,6 @@ For example, see this `edge-functions.code-workspace` configuration for a CRA (c
}
```
-## Running Edge Functions locally
-
-You can run your Edge Function locally using [`supabase functions serve`](/docs/reference/cli/usage#supabase-functions-serve):
-
-```bash
-supabase start # start the supabase stack
-supabase functions serve # start the Functions watcher
-```
-
-The `functions serve` command has hot-reloading capabilities. It will watch for any changes to your files and restart the Deno server.
-
-## Invoking Edge Functions locally
-
-While serving your local Edge Function, you can invoke it using curl:
-
-```bash
-curl --request POST 'http://localhost:54321/functions/v1/function-name' \
- --header 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24ifQ.625_WdcF3KHqz5amU0x2X5WWHP-OEs_4qj0ssLNHzTs' \
- --header 'Content-Type: application/json' \
- --data '{ "name":"Functions" }'
-```
-
-or using one of the [client libraries](/docs#reference-documentation), e.g. using [supabase-js](/docs/reference/javascript/functions-invoke):
-
-```js
-import { createClient } from '@supabase/supabase-js'
-
-// Use the credentials outputted in your terminal when running `supabase start`
-const supabase = createClient(
- 'http://localhost:54321',
- 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZS1kZW1vIiwicm9sZSI6ImFub24iLCJleHAiOjE5ODM4MTI5OTZ9.CRXP1A7WOeoJeXxjNni43kdQwgnWNReilDMblYTn_I0'
-)
-
-const { data, error } = await supabase.functions.invoke('function-name', {
- body: { name: 'Functions' },
-})
-```
-
-You should see the response `{ "message":"Hello Functions!" }`.
-
-If you execute the function with a different payload the response will change.
-Modify the `--data '{"name":"Functions"}'` line to `--data '{"name":"World"}'` and try invoking the command again!
-
-
-
-- Edge Functions don't serve HTML content (`GET` requests that return `text/html` are rewritten to `text/plain`).
-- The `Authorization` header is required. You can use either the `ANON` key, the `SERVICE_ROLE` key, or a logged-in user's JWT.
-- The Function is proxied through the local API (`http://localhost:54321`)
-
-
-
export const Page = ({ children }) =>
export default Page
diff --git a/apps/docs/pages/guides/functions/quickstart.mdx b/apps/docs/pages/guides/functions/quickstart.mdx
index a28f5bf4adf..6d847ca8bcf 100644
--- a/apps/docs/pages/guides/functions/quickstart.mdx
+++ b/apps/docs/pages/guides/functions/quickstart.mdx
@@ -2,32 +2,27 @@ import Layout from '~/layouts/DefaultGuideLayout'
export const meta = {
id: 'functions-quickstart',
- title: 'Edge Functions Quickstart',
- description: 'Globally distributed TypeScript Functions.',
- sidebar_label: 'Quickstart',
- video: 'https://www.youtube.com/v/rzglqRdZUQE',
+ title: 'Developing Edge Functions locally',
+ description: 'Get started with Edge Functions on your local machine.',
+ subtitle: 'Get started with Edge Functions on your local machine.',
+ tocVideo: 'rzglqRdZUQE',
}
-Learn how to build an Edge Function locally and deploy it to the Supabase Platform in less than 7 minutes.
+Let's create a basic Edge Function on your local machine and then invoke it using the Supabase CLI.
-
-
-
+## Initialize a project
-## Prerequisites
+Create a new Supabase project in a folder on your local machine:
-Follow the steps to prepare your Supabase project on your local machine.
+```bash
+supabase init
+```
-- Install the Supabase CLI. [Docs](/docs/guides/cli).
-- Login to the CLI using the command: `supabase login`. [Docs](/docs/reference/cli/usage#supabase-login).
-- Initialize Supabase inside your project using the command: `supabase init`. [Docs](/docs/guides/getting-started/local-development#getting-started).
-- Link to your Remote Project using the command `supabase link --project-ref your-project-ref`. [Docs](/docs/reference/cli/usage#supabase-link).
-- Setup your environment: Follow [the steps below](/docs/guides/functions/quickstart#setting-up-your-environment).
+
+
+Check out the [CLI Docs](/docs/guides/cli) to learn how to install the Supabase CLI on your local machine.
+
+
## Create an Edge Function
@@ -37,195 +32,99 @@ Let's create a new Edge Function called `hello-world` inside your project:
supabase functions new hello-world
```
-This creates a function stub in your `supabase` folder at `./functions/hello-world/index.ts`.
-
-## Deploy to production
-
-### Deploy a specific function
+This creates a function stub in your `supabase` folder:
```bash
-supabase functions deploy hello-world
+└── supabase
+ ├── functions
+ │ └── hello-world
+ │ │ └── index.ts ## Your function code
+ └── config.toml
```
-This command bundles your Edge Function from `./functions/hello-world/index.ts` and deploys it to the Supabase platform.
-The command outputs a URL to the Supabase Dashboard which you can open to find view more details. Let's open the link to find the execution command.
+## Running Edge Functions locally
-
-
-By default, Edge Functions require a valid JWT in the authorization header. This header is automatically set when invoking your function via a Supabase client library.
-
-If you want to use Edge Functions to handle webhooks (e.g. [Stripe payment webhooks](https://github.com/supabase/supabase/tree/master/examples/edge-functions/supabase/functions/stripe-webhooks) etc.), you need to pass the `--no-verify-jwt` flag when deploying your function.
-
-
-
-### Deploy all functions
+You can run your Edge Function locally using [`supabase functions serve`](/docs/reference/cli/usage#supabase-functions-serve):
```bash
-supabase functions deploy
+supabase start # start the supabase stack
+supabase functions serve # start the Functions watcher
```
-Since Supabase CLI [v1.62.0](https://github.com/supabase/cli/releases/tag/v1.62.0) you can deploy all functions with a single command. This is useful for example when [deploying with GitHub Actions](/docs/guides/functions/cicd-workflow).
+The `functions serve` command has hot-reloading capabilities. It will watch for any changes to your files and restart the Deno server.
-Individual function configuration like [JWT verification](/docs/guides/cli/config#functions.function_name.verify_jwt) and [import map location](/docs/guides/cli/config#functions.function_name.import_map) can be set via the `config.toml` file.
+## Invoking Edge Functions locally
-```toml
-[functions.hello-world]
-verify_jwt = false
-```
+While serving your local Edge Function, you can invoke it using curl or one of the client libraries:
-## Invoking remote functions
+
-You can invoke Edge Functions using curl:
-
-```bash
-curl --request POST 'https://.supabase.co/functions/v1/hello-world' \
- --header 'Authorization: Bearer ANON_KEY' \
+```bash cURL
+curl --request POST 'http://localhost:54321/functions/v1/hello-world' \
+ --header 'Authorization: Bearer SUPABASE_ANON_KEY' \
--header 'Content-Type: application/json' \
--data '{ "name":"Functions" }'
```
-
-
-If you receive an error `Invalid JWT`, find the `ANON_KEY` of your project in the Dashboard under `Settings > API`.
-
-
-
-or using one of the [client libraries](/docs#reference-documentation), e.g. using [supabase-js](/docs/reference/javascript/functions-invoke):
-
-```js
-// https://supabase.com/docs/reference/javascript/installing
+```js JavaScript
import { createClient } from '@supabase/supabase-js'
-// Create a single supabase client for interacting with your database
-const supabase = createClient('https://xyzcompany.supabase.co', 'public-anon-key')
+const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_ANON_KEY)
const { data, error } = await supabase.functions.invoke('hello-world', {
body: { name: 'Functions' },
})
```
-After invoking your Edge Function you should see the response `{ "message":"Hello Functions!" }`.
+
-### Error Handling
+
-When interacting with Edge Functions, it's important to be prepared for potential errors that might occur during the invocation. To handle errors effectively, the following error handling code can be used:
+Run `supabase status` to see your local credentials.
-```js
-import { FunctionsHttpError, FunctionsRelayError, FunctionsFetchError } from '@supabase/supabase-js'
+
-const { data, error } = await supabase.functions.invoke('hello', {
- headers: {
- 'my-custom-header': 'my-custom-header-value',
- },
- body: { foo: 'bar' },
-})
+You should see the response `{ "message":"Hello Functions!" }`.
-if (error instanceof FunctionsHttpError) {
- const errorMessage = await error.context.json()
- console.log('Function returned an error', errorMessage)
-} else if (error instanceof FunctionsRelayError) {
- console.log('Relay error:', error.message)
-} else if (error instanceof FunctionsFetchError) {
- console.log('Fetch error:', error.message)
-}
+If you execute the function with a different payload, the response will change.
+
+Modify the `--data '{"name":"Functions"}'` line to `--data '{"name":"World"}'` and try invoking the command again.
+
+## Next steps
+
+Check out the [Deploy to Production](/docs/guides/functions/deploy) guide to make your Edge Function available to the world.
+
+Read on for some common development tips.
+
+## Development tips
+
+Here are a few recommendations when developing Edge Functions.
+
+### Skipping Authorization checks
+
+By default, Edge Functions require a valid JWT in the authorization header. If you want to use Edge Functions without Authorization checks (commonly used for Stripe webhooks), you can pass the `--no-verify-jwt` flag when serving your Edge Functions locally.
+
+```bash
+supabase functions serve hello-world --no-verify-jwt
```
-In the provided error handling code, we're checking the type of error that occurred using the "instanceof" operator. This helps us differentiate between different types of errors and handle them appropriately. Depending on the type of error, we either log the error message or information specific to that type of error.
+Be careful when using this flag, as it will allow anyone to invoke your Edge Function without a valid JWT. The Supabase client libraries automatically handle authorization.
-This error handling mechanism ensures that your application can gracefully handle errors that might arise during the execution of Edge Functions, providing a more robust user experience.
+### Using HTTP Methods
-## Importing Node npm modules
+Edge Functions support `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, and `OPTIONS`. A Function can be designed to perform different actions based on a request's HTTP method. See the [example on building a RESTful service](https://github.com/supabase/supabase/tree/master/examples/edge-functions/supabase/functions/restful-tasks) to learn how to handle different HTTP methods in your Function.
-We recommend using [esm.sh](https://esm.sh/) for importing Node.js modules that are published to npm. To do so you simply put `https://esm.sh/` in front of the package name.
+
-For example, when you want to use supabase-js within Supabase Edge Functions, you would import `createClient` as follows:
+HTML content is not supported. `GET` requests that return `text/html` will be rewritten to `text/plain`.
-```ts
-import { createClient } from 'https://esm.sh/@supabase/supabase-js@2'
-```
+
-As long as your environment is set up properly and the module you're importing is exporting types, the import will have types and autocompletion support.
+### Naming Edge Functions
-## Setting Up Your Environment
+We recommend using hyphens to name functions because hyphens are the most URL-friendly of all the naming conventions (snake_case, camelCase, PascalCase).
-You can follow the [Deno guide](https://deno.com/manual@v1.32.5/getting_started/setup_your_environment) for setting up your development environment with your favorite editor/IDE.
-
-### Deno with Visual Studio Code (vscode)
-
-Install the Deno language server [via this link](vscode:extension/denoland.vscode-deno) or by browsing the extensions in vscode and choosing to install the _Deno_ extension.
-
-#### Partially Deno enabling a workspace
-
-In a given workspace (or workspace folder), sub-paths can be enabled for Deno, while code outside those paths will be not be enabled and the vscode built-in JavaScript/TypeScript language server will be used.
-
-For example if you have a project like this:
-
-```
-project
-├── app
-└── supabase
- └── functions
-```
-
-Where you only want to enabled the `supabase/functions` path (and its subpaths) to be Deno enabled, you will want to add `./supabase/functions` to the list of _Deno: Enable Paths_ in the configuration. In your `.vscode/settings.json` file add:
-
-```json
-{
- "deno.enablePaths": ["./supabase/functions"],
- "deno.importMap": "./supabase/functions/import_map.json"
-}
-```
-
-#### Multi-root workspaces
-
-Alternatively, you can utilize [multi-root workspaces](https://code.visualstudio.com/docs/editor/workspaces#_multiroot-workspaces).
-
-
-
-
-
-For example, see this `edge-functions.code-workspace` configuration for a CRA (create react app) client with Supabase Edge Functions. You can find the complete example on [GitHub](https://github.com/supabase/supabase/tree/master/examples/edge-functions).
-
-```json
-{
- "folders": [
- {
- "name": "project-root",
- "path": "./"
- },
- {
- "name": "client",
- "path": "app"
- },
- {
- "name": "supabase-functions",
- "path": "supabase/functions"
- }
- ],
- "settings": {
- "files.exclude": {
- "node_modules/": true,
- "app/": true,
- "supabase/functions/": true
- },
- "deno.importMap": "./supabase/functions/import_map.json"
- }
-}
-```
-
-## Database Functions vs Edge Functions
-
-For data-intensive operations we recommend using [Database Functions](/docs/guides/database/functions), which are executed within your database
-and can be called remotely using the [REST and GraphQL API](/docs/guides/api).
-
-For use-cases which require low-latency we recommend [Edge Functions](/docs/guides/functions), which are globally-distributed and can be written in TypeScript.
-
-## Organizing your Edge Functions
+### Organizing your Edge Functions
We recommend developing “fat functions”. This means that you should develop few large functions, rather than many small functions. One common pattern when developing Functions is that you need to share code between two or more Functions. To do this, you can store any shared code in a folder prefixed with an underscore (`_`). We also recommend a separate folder for [Unit Tests](/docs/guides/functions/unit-test) including the name of the function followed by a `-test` suffix.
We recommend this folder structure:
@@ -249,22 +148,43 @@ We recommend this folder structure:
└── config.toml
```
-## Naming Edge Functions
+### Using config.toml
-We recommend using hyphens to name functions because hyphens are the most URL-friendly of all the naming conventions (snake_case, camelCase, PascalCase).
+Individual function configuration like [JWT verification](/docs/guides/cli/config#functions.function_name.verify_jwt) and [import map location](/docs/guides/cli/config#functions.function_name.import_map) can be set via the `config.toml` file.
-## Using HTTP Methods
+```toml supabase/config.toml
+[functions.hello-world]
+verify_jwt = false
+import_map = './import_map.json'
+```
-Edge Functions supports `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, and `OPTIONS`. A function can be designed to perform different actions based on a request's HTTP method. See the [example on building a RESTful service](https://github.com/supabase/supabase/tree/master/examples/edge-functions/supabase/functions/restful-tasks) to learn how to handle different HTTP methods in your function.
+### Error Handling
-## Limitations
+The `supabase-js` library provides several error types that you can use to handle errors that might occur when invoking Edge Functions:
-- Deno Deploy limitations
- - Deno does not support outgoing connections to ports `25`, `465`, and `587`.
- - Cannot read or write to File System
- - NPM modules are not supported.
-- Edge Functions
- - Serving of HTML content is not supported (`GET` requests that return `text/html` will be rewritten to `text/plain`).
+```js
+import { FunctionsHttpError, FunctionsRelayError, FunctionsFetchError } from '@supabase/supabase-js'
+
+const { data, error } = await supabase.functions.invoke('hello', {
+ headers: { 'my-custom-header': 'my-custom-header-value' },
+ body: { foo: 'bar' },
+})
+
+if (error instanceof FunctionsHttpError) {
+ const errorMessage = await error.context.json()
+ console.log('Function returned an error', errorMessage)
+} else if (error instanceof FunctionsRelayError) {
+ console.log('Relay error:', error.message)
+} else if (error instanceof FunctionsFetchError) {
+ console.log('Fetch error:', error.message)
+}
+```
+
+### Database Functions vs Edge Functions
+
+For data-intensive operations we recommend using [Database Functions](/docs/guides/database/functions), which are executed within your database and can be called remotely using the [REST and GraphQL API](/docs/guides/api).
+
+For use-cases which require low-latency we recommend [Edge Functions](/docs/guides/functions), which are globally-distributed and can be written in TypeScript.
export const Page = ({ children }) =>
diff --git a/apps/docs/pages/guides/functions/regional-invocation.mdx b/apps/docs/pages/guides/functions/regional-invocation.mdx
index 994549bd9e4..2272a547d0d 100644
--- a/apps/docs/pages/guides/functions/regional-invocation.mdx
+++ b/apps/docs/pages/guides/functions/regional-invocation.mdx
@@ -2,26 +2,28 @@ import Layout from '~/layouts/DefaultGuideLayout'
export const meta = {
id: 'function-regional-invocation',
- title: 'Regional Invocation',
+ title: 'Regional Invocations',
description: 'How to execute an Edge Functions in a particular region.',
+ subtitle: 'How to execute an Edge Function in a particular region.',
}
-By default, Edge Functions are executed in the region closest to the user making the request. This helps to reduce network latency and provide faster responses to the user.
+Edge Functions are executed in the region closest to the user making the request. This helps to reduce network latency and provide faster responses to the user.
-However, if your function does lot of database or storage operations, invoking the function in the same region as your DB may provide better performance.
-
-Some situations where this might be helpful include:
+However, if your Function performs lots of database or storage operations, invoking the Function in the same region as your database may provide better performance. Some situations where this might be helpful include:
- Bulk adding and editing records in your database
- Uploading files
-If you prefer to do this, you can specify the region when invoking the function.
+Supabase provides an option to specify the region when invoking the Function.
-### How to set the region via HTTP headers
+## Using the `x-region` header
-Use the `x-region` HTTP header when calling an Edge Function to determine where the Function should be executed.
+Use the `x-region` HTTP header when calling an Edge Function to determine where the Function should be executed:
-```bash
+
+
+```bash cURL
+# https://supabase.com/docs/guides/functions/deploy#invoking-remote-functions
curl --request POST 'https://.supabase.co/functions/v1/hello-world' \
--header 'Authorization: Bearer ANON_KEY' \
--header 'Content-Type: application/json' \
@@ -29,24 +31,25 @@ curl --request POST 'https://.supabase.co/functions/v1/hello-world'
--data '{ "name":"Functions" }'
```
-You can also specify the region using the [client libraries](/docs#reference-documentation), such as [supabase-js](/docs/reference/javascript/functions-invoke):
-
-```js
+```js JavaScript
// https://supabase.com/docs/reference/javascript/installing
import { createClient } from '@supabase/supabase-js'
// Create a single supabase client for interacting with your database
const supabase = createClient('https://xyzcompany.supabase.co', 'public-anon-key')
+// https://supabase.com/docs/reference/javascript/functions-invoke
const { data, error } = await supabase.functions.invoke('hello-world', {
body: { name: 'Functions' },
headers: { 'x-region': 'eu-west-3' },
})
```
-You can verify the region the function was executed by looking at the `x-sb-edge-region` HTTP header in the response. You can also find it as metadata in [Edge Function Logs](/docs/guides/functions/debugging)
+
-### Supported regions
+You can verify the execution region by looking at the `x-sb-edge-region` HTTP header in the response. You can also find it as metadata in [Edge Function Logs](/docs/guides/functions/debugging).
+
+## Available regions
These are the currently supported region values you can provide for `x-region` header.
@@ -65,9 +68,9 @@ These are the currently supported region values you can provide for `x-region` h
- `us-west-1`
- `us-west-2`
-### What happens if the region has an outage?
+## Handling regional outages
-If you explicitly specify the region via `x-region` header, the **request won't be automatically re-routed** to another region.
+If you explicitly specify the region via `x-region` header, requests **will NOT** be automatically re-routed to another region and you should consider temporarily changing regions during the outage.
export const Page = ({ children }) =>
diff --git a/apps/docs/pages/guides/functions/secrets.mdx b/apps/docs/pages/guides/functions/secrets.mdx
index 8259d4e2d12..81f59125dd7 100644
--- a/apps/docs/pages/guides/functions/secrets.mdx
+++ b/apps/docs/pages/guides/functions/secrets.mdx
@@ -2,8 +2,9 @@ import Layout from '~/layouts/DefaultGuideLayout'
export const meta = {
id: 'functions-secrets',
- title: 'Managing Secrets and Environment Variables',
+ title: 'Managing Environment Variables',
description: 'Managing secrets and environment variables.',
+ subtitle: 'Managing secrets and environment variables.',
}
It's common that you will need to use sensitive information or environment-specific variables inside your Edge Functions. You can access these using Deno's built-in handler
@@ -12,25 +13,21 @@ It's common that you will need to use sensitive information or environment-speci
Deno.env.get(MY_SECRET_NAME)
```
-### Local Development
+## Default secrets
-When developing functions locally, you will be able to load environment variables in two ways:
-
-1. Through a default `.env` file placed at `supabase/functions/.env`, which will get loaded on `supabase start`
-2. Through the `--env-file` option for `supabase functions serve`, for example: `supabase functions serve --env-file ./path/to/.env-file`
-
-To perform a one-time setup of your local development secrets, use the first option to create the `.env` file that will apply to all functions.
-
-### Default secrets
-
-By default, Edge Functions have access to these secrets:
+Edge Functions have access to these secrets by default:
- `SUPABASE_URL`: The API gateway for your Supabase project.
- `SUPABASE_ANON_KEY`: The `anon` key for your Supabase API. This is safe to use in a browser when you have [Row Level Security](/docs/guides/auth/row-level-security) enabled.
- `SUPABASE_SERVICE_ROLE_KEY`: The `service_role` key for your Supabase API. This is safe to use in Edge Functions, but it should NEVER be used in a browser. This key will bypass [Row Level Security](/docs/guides/auth/row-level-security).
- `SUPABASE_DB_URL`: The URL for your [PostgreSQL database](/docs/guides/database). You can use this to connect directly to your database.
-### Local secrets
+## Local secrets
+
+You can load environment variables in two ways:
+
+1. Through an `.env` file placed at `supabase/functions/.env`, which is automatically loaded on `supabase start`
+2. Through the `--env-file` option for `supabase functions serve`, for example: `supabase functions serve --env-file ./path/to/.env-file`
Let's create a local file for storing our secrets, and inside it we can store a secret `MY_NAME`:
@@ -60,7 +57,7 @@ supabase functions serve --env-file ./supabase/.env.local
When the function starts you should see the name “Yoda” output to the terminal.
-### Production secrets
+## Production secrets
Let's create a `.env` for production. In this case we'll just use the same as our local secrets:
diff --git a/apps/docs/pages/guides/functions/troubleshooting.mdx b/apps/docs/pages/guides/functions/troubleshooting.mdx
deleted file mode 100644
index 33e0978d261..00000000000
--- a/apps/docs/pages/guides/functions/troubleshooting.mdx
+++ /dev/null
@@ -1,64 +0,0 @@
-import Layout from '~/layouts/DefaultGuideLayout'
-
-export const meta = {
- id: 'functions-troubleshooting',
- title: 'Troubleshooting Edge Functions',
- description: 'Troubleshooting Supabase Edge Functions.',
-}
-
-## Unable to call Edge Function
-
-If you're unable to call your Edge Function or are experiencing any CORS issues, even though you followed the [CORS guide](/docs/guides/functions/cors), please head over to [supabase.com/dashboard/project/\_/functions](https://supabase.com/dashboard/project/_/functions), select your function from the list & click Logs. Do you see any errors listed there?
-
-There are two debugging tools available: Invocations and Logs. Invocations shows the Request and Response for each execution, while Logs shows any platform events, including deployments and errors.
-
-## Unable to deploy Edge Function
-
-- Make sure you're on the latest version of the [Supabase CLI](/docs/guides/cli#updates).
-- Run the deploy command with the `--debug` flag.
-- Run the deploy command with the `--legacy-bundle` flag and see if that works.
-- If the output from the commands above does not help you to resolve the issue, please open a support ticket via the Supabase Dashboard (by clicking the "Help" button at the top right) and include all output from the commands mentioned above.
-
-## Edge Function takes too long to respond
-
-- Head over to [supabase.com/dashboard/project/\_/functions](https://supabase.com/dashboard/project/_/functions), select your function from the list & click Logs.
-- In the logs, look for the `booted` event and check if they have consistent boot times.
- - If the boot times are similar, it's likely an issue with your function's code, like a large dependency etc.
- - If only some of the `booted` events are slow, please find the affected `region` in the metadata and submit a support request via the "Help" button at the top.
-
-## Issues serving Edge Functions locally with the Supabase CLI
-
-- Make sure you're on the latest version of the [Supabase CLI](/docs/guides/cli#updates).
-- Run the serve command with the `--debug` flag.
-- Support engineers can then try to run the provided sample code locally and see if they can reproduce the issue.
-- Search the [Edge Runtime](https://github.com/supabase/edge-runtime) and [CLI](https://github.com/supabase/cli) repos for the error message, to see if it has been reported before.
-- If the output from the commands above does not help you to resolve the issue, please open a support ticket via the Supabase Dashboard (by clicking the "Help" button at the top right) and include all output and details about your commands.
-
-# Advanced Techniques
-
-## Checking Function Boot Time
-
-Check the logs for the function. In the logs, look for a "Booted" event and note the reported boot time. If available, click on the event to access more details, including the regions from where the function was served. Investigate if the boot time is excessively high (`higher than 1 second`) and note any patterns or regions where it occurs.
-
-## Finding Bundle Size
-
-To find the bundle size of a function, run the following command locally:
-
-```bash
-deno info /path/to/function/index.ts
-```
-
-Look for the "size" field in the output which represents an approximated the bundle size of the function.You can find the accurate bundle size when you deploy your function via Supabase CLI. If the function is part of a larger application, consider examining the bundle size of the specific function independently.
-
-## Analyze Dependencies
-
-Review the dependencies listed in the output of the `deno info` command. Pay attention to any significantly large dependencies, as they can contribute to increased bundle size and potential boot time issues.
-Examine if there are any unnecessary or redundant dependencies that can be removed. Check for outdated dependencies and recommend updating to the latest versions if applicable. When running deno info make sure to provide the correct path of the import map if you use one.
-
-```bash
-deno info --import-map=/path/to/import_map.json /path/to/function/index.ts
-```
-
-export const Page = ({ children }) =>
-
-export default Page
diff --git a/apps/docs/pages/guides/functions/typescript-support.mdx b/apps/docs/pages/guides/functions/typescript-support.mdx
deleted file mode 100644
index 7816f28fac7..00000000000
--- a/apps/docs/pages/guides/functions/typescript-support.mdx
+++ /dev/null
@@ -1,54 +0,0 @@
-import Layout from '~/layouts/DefaultGuideLayout'
-
-export const meta = {
- id: 'functions-debugging',
- title: 'TypeScript Support',
- description: 'Using TypeScript in Deno Edge Functions.',
-}
-
-One of the benefits of Deno is that it treats TypeScript as a first class
-language, just like JavaScript or Web Assembly, when running code in Deno. What
-that means is you can run or import TypeScript without installing anything more
-than the Deno CLI.
-
-## How does it work?
-
-At a high level, Deno converts TypeScript (as well as TSX and JSX) into
-JavaScript. It does this via a combination of the
-[TypeScript compiler](https://github.com/microsoft/TypeScript), which we build
-into Deno, and a Rust library called [swc](https://swc.rs/). When the code has
-been type checked and transformed, it is stored in a cache, ready for the next
-run without the need to convert it from its source to JavaScript again.
-
-## Strict by default
-
-Deno type checks TypeScript in _strict_ mode by default, and the TypeScript core
-team recommends _strict_ mode as a sensible default. This mode generally enables
-features of TypeScript that probably should have been there from the start, but
-as TypeScript continued to evolve, would be breaking changes for existing code.
-
-## Mixing JavaScript and TypeScript
-
-By default, Deno does not type check JavaScript. This can be changed, and is
-discussed further in [Configuring TypeScript in Deno](https://deno.com/manual/advanced/typescript/configuration). Deno
-does support JavaScript importing TypeScript and TypeScript importing
-JavaScript, in complex scenarios.
-
-An important note though is that when type checking TypeScript, by default Deno
-will "read" all the JavaScript in order to be able to evaluate how it might have
-an impact on the TypeScript types. The type checker will do the best it can to
-figure out what the types are of the JavaScript you import into TypeScript,
-including reading any JSDoc comments. Details of this are discussed in detail in
-the [Types and type declarations](https://deno.com/manual/advanced/typescript/types) section.
-
-## Type resolution
-
-One of the core design principles of Deno is to avoid non-standard module
-resolution, and this applies to type resolution as well. If you want to utilize
-JavaScript that has type definitions (e.g. a `.d.ts` file), you have to
-explicitly tell Deno about this. The details of how this is accomplished are
-covered in the [Types and type declarations](https://deno.com/manual/advanced/typescript/types) section.
-
-export const Page = ({ children }) =>
-
-export default Page
diff --git a/apps/docs/pages/guides/functions/unit-test.mdx b/apps/docs/pages/guides/functions/unit-test.mdx
index ef23086e14b..0006dc6869e 100644
--- a/apps/docs/pages/guides/functions/unit-test.mdx
+++ b/apps/docs/pages/guides/functions/unit-test.mdx
@@ -4,15 +4,37 @@ export const meta = {
id: 'unit-test',
title: 'Testing your Edge Functions',
description: 'Writing Unit Tests for Edge Functions using Deno Test',
+ subtitle: 'Writing Unit Tests for Edge Functions using Deno Test',
}
Testing is an essential step in the development process to ensure the correctness and performance of your Edge Functions.
-When creating test files for Edge Functions, it is recommended to place them in the `supabase/tests` directory and name the file by the function name followed by `-test.ts`. For example, `hello-world-test.ts`.
+## Testing in Deno
-```typescript
-// deno-test.ts
+Deno has a built-in test runner that you can use for testing JavaScript or TypeScript code. You can read the [official documentation](https://docs.deno.com/runtime/manual/basics/testing/) for more information and details about the available testing functions.
+## Folder structure
+
+We recommend creating your testing in a `supabase/tests` directory, using the same name as the Function followed by `-test.ts`:
+
+```bash
+└── supabase
+ ├── functions
+ │ ├── function-one
+ │ │ └── index.ts
+ │ └── function-two
+ │ │ └── index.ts
+ │ └── tests
+ │ └── function-one-test.ts # Tests for function-one
+ │ └── function-two-test.ts # Tests for function-two
+ └── config.toml
+```
+
+## Example script
+
+The following script is a good example to get started with testing your Edge Functions:
+
+```typescript function-one-test.ts
// Import required libraries and modules
import {
assert,
@@ -93,7 +115,7 @@ Please make sure to replace the placeholders (`supabaseUrl`, `supabaseKey`, `my_
-### Running Edge Functions Locally
+## Running Edge Functions Locally
To locally test and debug Edge Functions, you can utilize the Supabase CLI. Let's explore how to run Edge Functions locally using the Supabase CLI:
@@ -127,7 +149,7 @@ To locally test and debug Edge Functions, you can utilize the Supabase CLI. Let'
4. To run the tests, use the following command in your terminal:
```bash
- deno test --allow-all deno-test.ts --env-file .env.local
+ deno test --allow-all supabase/functions/function-one-test.ts --env-file .env.local
```
## Resources
diff --git a/apps/www/lib/redirects.js b/apps/www/lib/redirects.js
index 93edbf97994..9daf63e354f 100644
--- a/apps/www/lib/redirects.js
+++ b/apps/www/lib/redirects.js
@@ -2328,4 +2328,14 @@ module.exports = [
source: '/docs/guides/functions/global-deployments',
destination: '/docs/guides/functions/regional-invocation',
},
+ {
+ permanent: true,
+ source: '/docs/guides/functions/typescript-support',
+ destination: '/docs/guides/functions',
+ },
+ {
+ permanent: true,
+ source: '/docs/guides/functions/troubleshooting',
+ destination: '/docs/guides/functions/debugging',
+ },
]