How to properly utilize the AdminClient Server Side?

[corcorpj]

Hello -

I am new to Supbase integration but severely struggling with the design patterns presented around Supabase.Client, the Supabase.GoTrue.AdminClient, and the Supabase.GoTrue.StatelessClient for deployment within an ASP.NET server side application.

As a general REST API providing business logic and integration with Supabase - the Supabase.Client as a system that allows internal state and session mutation is fundamentally an anti-pattern to asynchronous and concurrent API request handling. I feel like a common use case for Supabase integration would be server-side applications (who unto themselves are issued security keys) would be able to execute privileged requests through the Supabase API without session mutation --- upon further reading, perhaps they can?

Supabase.Client.Auth and Supbase.Client.Auth.Admin - here presented (2) more libraries, that seems to bifurcate the public/private surface within Supabase but Admin depends on Auth which depends on the stateful Supabase.Client - so again we are left with uncertainty around consumption an utilization in concurrent web request pipeline.

Or possibly more obscure//arguably bad security practice - the AdminClient is stated to be stateless unto itself - provided you construct it with a valid JWT, which you cannot generate through Supabase controlled surfaces for the updated API Keys, nor does Supabase continue to use shared symmeteric keys - therefore, you are left with manually minting JWTs from asymmetric signing keys, (also manually generated) but the generation process and requirements are not descride in this project or the documentation outside of the Unit Testing examples for ServiceRole and StatelssClient.

What am I misunderstanding about server-side integration with Supabase? If we are consuming what is fundamentally and HTTP surface in C# it feels the SDK abstraction has gone sideways on allow secure server communication with the Supabase platform? Why is minting your own JWTs required for server side integration in a stateless fashion? Is there any planned develpment support for using the updated API Keys Supabase offers? I'd be willing to help contribute, but I am clearly completely lost on this SDKS architecture and interpretation of Clients and integration with .NET. The closest pattern presented for ASP is the MAUI DI pattern, which ignores the potential problems with concurrent session mutation during service level user management in a singleton.

Honestly, I feel like I have missed something massive in the design intention? This discussion is maybe asking for clarity on how these SDKs are to be used for basic operations like creating and updating users (from the server) without mutating the state of the Supabase.Client on the server?

[corcorpj]

I just have to reiterate, a stateful implementations in singleton patterns is not best practice - https://learn.microsoft.com/en-us/dotnet/core/extensions/dependency-injection-guidelines

[corcorpj]

This is massively outdated - https://github.com/supabase-community/supabase-csharp/wiki/Server-Side-Applications

[wiverson]

My two cents - for the vast majority of C# users writing REST services or traditional SSR apps, you probably don't need this library at all. Use the Supabase JavaScript/TypeScript SDK on the client, and just connect to the Postgres instance via your vanilla SQL integration strategy of choice, be it Entity Framework, an ORM or whatever you prefer.

There are a handful of things like Auth that you will find much easier to deal with using the JavaScript SDK. If you use (asymmetric) JWTs you can auth those on your backend via cookie or params as you wish from the JWT obtained by the JavaScript SDK.

You might find it interesting to write your Supabase functions using PostgREST and access those via RPC, either using the JavaScript SDK or on the server using your REST strategy of choice.

The primary practical use for this library IMHO is for C#/.NET client-side software, like a Unity or Godot project. I suppose there's a tiny subset of folks writing traditional C# client side apps but it's a very, very tiny userbase at this point.

This library can be used stateless, but IMHO you are then just using it as a less well adopted version of a REST client and ORM.

[corcorpj]

Well without any of this background, and the documentation on Supabase.com - I disagree that the default assumptions of .NET developers align with this understanding. Like when a seemingly well supported SDK exists - my first instinct would not be to implement my own HTTP Client wrapper from scratch, hence the SDK.

It's likely obvious from me even bringing this up, but I have a use case that favors centralizing application management through my own central API, and doesn't play nice with default use cases of the Javascript first implementation around auth. The main reason I was hopeful for this SDK integration is for tertiary Supabase integrations like Auth - that are not directly accessible via ORM - which I use for standard Db interaction. There are also plenty of examples like progressive enrollment that would tend toward a server side integration outside of the users direct browsing session. Why is it unreasonable for a sever-side app to integrate with Supabase directly?

[wiverson]

Well, not sure what to tell you. You can use this library stateless on the server. You can connect directly to Postgres. There are REST APIs you can use. If you are building an administrative tool that manages Supabase projects, that's fine but it's also not a very common use case, but AFAIK there are working APIs for that. IIRC there are stateless administrative functions in this SDK that you can use.

[corcorpj]

I don't believe the SDKs stateless implementation has kept up with Supabase security changes to both service role keys and JWT - furthermore the 'stateless' client is not actually stateless. As described in the older wiki in the root Supabase c# repository. The lack of immutability about what is described as a stateless session, and the current solution-ing around one-the-fly token generation is pretty wild.

I was sincerely trying to understand how people use this SDK because I have felt at every turn there's significant behavior differences between what I expect (given other SDKs that wrap platform APIs like Sendgrid, Twilio, Snowflake, etc.) and how this one is constructed.

I also said I'd be willing to help, but again I feel like my perception is so different form the designers I'm not sure I can even understand the premise of the problems this SDK is solving.

[wiverson]

Yeah, if you look at the repo dates I don't think there's a current maintainer so I'm not surprised if things have gotten out of sync. I was doing some work on a Unity specific project a while ago, so I made a few contributions for that for auth, including also some quick tests on Godot as well. The main surface area I was interested in were auth for a Unity client and also the rpc functionality to hit PostgREST resources.

I personally find a lot of the GraphQL-centric ORM-ish Entity Framework-ish stuff in this repo to be confusing and hard to maintain. I think that they originally should have broken it into two repos, a client-specific one and a server one, but that's just my take. Given how confusing .NET runtimes are, all of the different stacks, etc. it's a lot of work but no maintainers. I have to go to an apt, I think maybe adding a note to the main README for status might be a good idea.