vasceannie/supabase
1
0
Fork 0
Code Issues Pull Requests Actions 8 Packages Projects Releases Wiki Activity

feat: update docs and blog to promote experimental routing to ga (#34802)

Browse Source 
* feat: update docs and blog to promote experimental routing to ga

* supabase services not geo-routing enabled yet

---------

Co-authored-by: Wen Bo Xie <wenbo.xie3@gmail.com>
Co-authored-by: Wen Bo Xie <5532241+w3b6x9@users.noreply.github.com>
This commit is contained in:
Crispy
2025-04-10 09:45:11 +01:00
committed by GitHub
parent 04600dd711
commit 044fa3858a
3 changed files with 9 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
apps/docs/content/guides/platform/read-replicas.mdx
View File

@@ -97,30 +97,19 @@ A connection pool through Supavisor is also available for each Read Replica. Fin
A load balancer is deployed to automatically balance requests between your Primary database and Read Replicas. Find its endpoint on the [API Settings page](/dashboard/project/_/settings/api).
The load balancer uses a round-robin strategy to route `GET` requests to all available API endpoints, including the Primary database. This means that `GET` requests are randomly and evenly split among databases. Non-`GET` requests can also be sent through this endpoint, and will be routed to the Primary database.
The load balancer enables geo-routing for Data API requests so that `GET` requests will automatically be routed to the Read Replica that is closest to your user ensuring the lowest latency. Non-`GET` requests can also be sent through this endpoint, and will be routed to the Primary database.
To call a read-only Postgres function on Read Replicas through the REST API, use the `get: true` [option](/docs/reference/javascript/rpc?queryGroups=example&example=call-a-read-only-postgres-function).
If you remove all Read Replicas from your project, the load balancer and its endpoint are removed as well. Make sure to redirect requests back to your Primary database before removal.
#### Experimental routing
The API load balancer offers an experimental routing mode that builds on top of the existing functionality. It is now possible to use a load balancer endpoint for all Supabase services (Auth, Edge Functions, Realtime, and Storage) meaning there is no need to worry about which endpoint to use in which situations.
You can also interact with Supabase services (Auth, Edge Functions, Realtime, and Storage) through this load balancer so there's no need to worry about which endpoint to use and in which situations. However, geo-routing for these services are not yet available but is coming soon.
<Admonition type="note">
Due to the requirements of the Auth service, all Auth requests are handled by the Primary, even when sent over the load balancer endpoint. This is similar to how non-Read requests for the Data API (PostgREST) are exclusively handled by the Primary.
Additionally:
- Pre-signed URLs generated by the Storage service currently do not work with experimental routing. You can either manually remove the `-all` suffix from the hostname of the generated URL, or use a non-LB client to generate the pre-signed URL.
- Realtime is known to have an issue when used in conjunction with experimental routing and an LB endpoint, for now it should be used via a non-LB client to ensure correct functionality.
These limitation will be resolved in the coming weeks.
</Admonition>
The experimental routing mode can be enabled by sending the header `sb-lb-routing-mode: alpha-all-services` along with requests. This gives the option to opt-in and try out the new routing, but still have the peace of mind that the original behavior is there should it be needed.
To call a read-only Postgres function on Read Replicas through the REST API, use the `get: true` [option](/docs/reference/javascript/rpc?queryGroups=example&example=call-a-read-only-postgres-function).
If you remove all Read Replicas from your project, the load balancer and its endpoint are removed as well. Make sure to redirect requests back to your Primary database before removal.
<Admonition type="note">
Starting on April 4th, 2025, we will be changing the routing behavior for eligible Data API requests:
@@ -132,53 +121,6 @@ The new behavior delivers a better experience for your users by minimizing the l
</Admonition>
What follows is an example of using the `supabase-js` library to create a new client with the appropriate headers and make an Auth request to create a new user.
```ts ./create-user.ts
import { createClient } from '@supabase/supabase-js'
import * as dotenv from 'dotenv'
// Load environment variables from .env file
dotenv.config()
// Supabase credentials
const supabaseUrl = process.env.SUPABASE_URL as string
const supabaseKey = process.env.SUPABASE_KEY as string
// Initialize the Supabase client with custom headers
const supabase = createClient(supabaseUrl, supabaseKey, {
global: {
headers: {
'sb-lb-routing-mode': 'alpha-all-services',
},
},
})
/**
* @description simple user creation function
*/
async function createUser() {
// Make the Auth call to create a user
const { data, error } = await supabase.auth.signUp({
email: 'valid.email@supabase.io',
password: 'my--really-strong-password',
})
// Throw on an error
if (error) {
throw new Error(error.message)
}
// Output the response
console.dir(data)
}
// Register a random user
createUser()
```
The client creation function, with experimental routing header, can be used throughout an application to take advantage of load balancer experimental routing.
<Admonition type="caution">
If you use a [custom domain](/docs/guides/platform/custom-domains), requests will not be routed through the load balancer. You should instead use the dedicated endpoints provided in the dashboard.

11
apps/www/_blog/2025-04-04-data-api-nearest-read-replica.mdx
View File

@@ -17,7 +17,7 @@ launchweek: 14
Today we’re releasing Data API requests routing to the nearest Read Replica by extending our [API load balancer](/docs/guides/platform/read-replicas#api-load-balancer) to handle geo-routing.
It’s an impactful improvement that will minimize request latency for your globally distributed applications. It’s only available today when [experimental routing](/docs/guides/platform/read-replicas#experimental-routing) is enabled.
It’s an impactful improvement that will minimize request latency for your globally distributed applications. It’s available by default when using a load balancer endpoint.
## What is geo-routing?
@@ -55,14 +55,10 @@ To get the most from geo-routing, deploy read replicas in regions where your use
As an initial release, geo-routing is available with the following limitations:
- Currently limited to read-only Data API (PostgREST) requests
- Only available via experimental routing
If you're already using our API load balancer with experimental routing enabled, there's nothing you need to do; geo-routing is automatically applied to your Data API requests.
If you're already using our API load balancer there's nothing you need to do; geo-routing is automatically applied to your Data API requests.
Otherwise, you can enable this feature:
1. Ensure your project is using the API load balancer endpoint (`<project_ref>-all.supabase.co`)
2. Enable experimental routing (see [experimental routing](/docs/guides/platform/read-replicas#experimental-routing))
Otherwise, you can enable this feature by ensuring your project is using the API load balancer endpoint (`<project_ref>-all.supabase.co`)
We're actively working on expanding geo-routing support to other Supabase products, such as Auth, Storage, and Realtime. Stay tuned for updates.
@@ -70,5 +66,4 @@ We're actively working on expanding geo-routing support to other Supabase produc
As always, we welcome your feedback, let us know what you think!
- Check out the docs on [experimental routing](/docs/guides/platform/read-replicas#experimental-routing)
- [Sign up for Supabase](/dashboard/sign-up) and get started today

2
apps/www/_blog/2025-04-04-launch-week-14-top-10.mdx
View File

@@ -31,7 +31,7 @@ We’re extended Realtime Broadcast to enable sending messages from database tri
## #3: Route Data API Requests to the Nearest Read Replica
You can now route your Data API (PostgREST) requests to the nearest Read Replica to minimize network latency. This is only available today on experimental routing but we expect to make it the default in the coming days.
You can now route your Data API (PostgREST) requests to the nearest Read Replica to minimize network latency. This is available today as the default for all load balancer endpoints.
[Read more →](/blog/data-api-nearest-read-replica)