Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to override Supabase service URLs in client #443

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

marcinkoziej
Copy link

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.

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.)
@marcinkoziej
Copy link
Author

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

@marcinkoziej
Copy link
Author

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

@kangmingtay
Copy link
Member

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
Copy link
Member

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

@soedirgo soedirgo closed this Sep 28, 2022
@marcinkoziej
Copy link
Author

@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.

@soedirgo soedirgo reopened this Oct 11, 2022
@MagnusHJensen
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants