Clarify Desktop/Mobile vs Server Classes

[wiverson]

I'm thinking that perhaps it might make sense to remove the Admin JWT methods from the stateful client. Here's my thoughts:

1. Confusing for new dev. There's the admin key and the regular public key, and it's a bit confusing when getting started as to the usage.
2. Implicitly pushing a dev to bundle their admin key into a client app. It would be really easy for a dev to look at the docs, see "oh, I use an admin key to create a new user to sign up" and then the next thing you know they are bundling an admin key into their client app.
3. Probably not a good usage scenario to encourage long-running local stateful client objects on the server. Pretty much every server environment is going to want to just use the stateless calls. Certainly stuff like the background thread token refresh is almost certain a very Bad Idea(tm) on a server.

To start this might just be a documentation issue - basically just writing up the recommended configuration for desktop/mobile vs server usage. Then maybe remove the admin JWT methods from the stateful client?

If it was a clean start I would suggest two main usage scenarios, a stateful class for desktop/mobile clients with the nice stuff there (background thread, persistence, etc) and a stateless admin JWT class explicitly for server usage (perhaps with a little demo server app)? Not sure about naming, ClientClient and ServerClient are of course terrible lol. UserClient and ServerClient?

I'm guessing this would ripple through to at least affect the other projects as well. Just putting this out there as a starting point for discussion...

[acupofjose]

Tbh, this is the direction that the JS client took a few versions back. Originally it was all in one client before they separated into an "Admin" and "regular" client. AFAICT this would really only affect the gotrue-csharp library as it's the only one that the admin JWT is particularly useful for.

Ideally I'd like to separate a GotrueAdminClient and GotrueAdminApi out of the existing featureset!

But, otherwise, yes! This is largely a documentation issue that is easily fixed.