RFC: Split client-side SDK from admin (service role) SDK

[nicholaschiang]

trafficstars

Describe the problem

Currently, the admin methods like "Delete user" that require a full-access API key (e.g. service_role key) are documented side-by-side with the more client facing methods like signUp or signOut (that I think only require a public API key).

I will likely only use the admin methods in a server-side environment (because I should never send a service_role key to a client). I will likely not use any of the client-side methods (e.g. signUp, signIn, signOut) in that server-side environment. For the same reasons, I will never use the admin methods in a client-side environment. Thus, it doesn't make any sense to increase the client-side bundle by including methods that will only ever be called on the server-side (and vice versa).

Describe the improvement

I think this library should be refactored into two separate JavaScript libraries:

1. A Node.js admin SDK - For server-side environments, only includes admin methods that require a service_role key.
2. A JavaScript client-side SDK - To be bundled with client-side code, only includes methods called client-side.

And then the documentation should be updated accordingly: split (much like the Firebase Authentication docs and reference) into two sections, one for the admin SDK and one for the client-side SDK.

Additional context

This is how the Firebase Authentication SDKs are structured and I think it makes a lot of sense to reproduce a similar structuring here with Supabase Auth. Especially because I think that every REST API method included in the GoTrue /admin endpoints should be reproduced in a server-side admin SDK (e.g. like how the DELETE /admin/users/{user_id} was wrapped in #85).

For example, I'd like to be able to programmatically create new users without them having to login client-side.

[kiwicopple]

Agreed @nicholaschiang .

We actually have the gotrue library documented separately here: https://supabase.io/docs/gotrue/client/gotrue-client

But I think we should do something similar on the supabase-js wrapper.

[nicholaschiang]

@kiwicopple I'd be happy to help out with this if you can give me some pointers as to how best structure a new admin SDK. I'm migrating Tutorbook over to Supabase and I'm going to be wrapping these admin API endpoints myself anways. I might as well put those wrappers into a reusable "official" Supabase admin SDK that anyone can use...

[hf]

We've recently been discussing this and decided not to produce separate admin + client SDKs / libraries as we believe:

1. They introduce unnecessary complexity for maintenance, documentation, publishing, security updates
2. Versioning becomes hard and we've seen both with Firebase and Auth0 libraries that it can sometimes be very hard to orchestrate the correct versions of SDKs

Thank you all for your feedback!