Allow to override Supabase service URLs in client

[marcinkoziej]

Add 4 options to SupabaseClient that allow to set urls for Supabase
services: REST, Realtime, Auth, Storage, by option keys restUrl,
realtimeUrl, authUrl and storageUrl. The option should contain full
url (eg. https://foo.com/auth/v1 for GoTrue hosted at such url.)

What kind of change does this PR introduce? What is the current behavior?

Current SupabaseClient behaviour is to accept an url to Supabase instance, and construct sub-service urls by appending paths (/rest/v1, /auth/v1 etc).
This change allows to override the urls by passing them in options, when for example in self-hosting context such services run under different domains.

Please link any relevant issues here.

This solution helps to mitigate lack of custom domain support in Supabase.
Thanks to generously decoupled architecture, we will be able to just self-host GoTrue under our custom domain, and use SaaS Supabase. For this to work, we need to pass authUrl that points to our custom GoTrue instance.

What is the new behavior?

The new behaviour is same, unless options are used to override URLs for Supabase sub-services.

[marcinkoziej]

I just noticed this is a duplicate of PR supabase/supabase#399 - almost identical but a bit more concise.

[marcinkoziej]

Hey Supabase team! This is a very small change, can you review?

[kangmingtay]

Hey @marcinkoziej, this change isn't particularly necessary if you intend to just self-host gotrue. Have you tried using the gotrue-js client directly instead? You can directly instantiate the GoTrueClient class here with the url pointing to your self-hosted domain. At Supabase, we also use gotrue for auth and we use the gotrue-js client lib directly rather than changing the domain in the supabase-js client lib.

[soedirgo]

I'll close this for inactivity, but for folks bumping into the issue mentioned by OP, my recommendation is to use an API gateway to route the /*/v1 endpoints. E.g. on our self-hosted setup: https://github.com/supabase/supabase/blob/c117ae67eb376e997a9e2d04e457a3c174e75df7/docker/volumes/api/kong.yml

[marcinkoziej]

@kangmingtay sorry for late reply.

We want to use Supabase (so all the services via SupabaseClient) but to host gotrue ourselves (so that we can use custom domain for Google OIDC and our email server).
So we want to point SupabaseClient to our gotrue, but use Supabase hosted Storage, PostgREST etc.

Because of how SupabaseClient is encapsulated using TS OO primitives, it is impossible to override only authUrl.

I could change the client.auth after creating the client, but the constructor has already added some listeners to a default gotrue client - which looks like there will be some conflicts in there.
I could subclass and change the constructor, copy-paste most of it and just change the auth url, but the constructor calls private methods so they will not be usable.

My point is the style of how SupabaseClient is coded, does not really make its extension possible or even easy.
I think Object Oriented should mean that it's possible! Otherwise, lets use functional, not OO style of coding there.

@soedirgo yeah I could proxy all the api calls, but why? This will be less reliable and slower. i'd like only serve Auth api, rest should go straight to my Supabase project.

[MagnusHJensen]

This a really simple change, and I don't see the problem with it.
As mentioned, you might want to use supabase overall, but self-host only one service and then it becomes tedious to run supabase-js and gotrue-js as seperate clients, instead of just being able to override the URL's.