Open OverGreed opened 1 year ago
hi @OverGreed, instead of creating a shared client on the backend, you should be creating a client on every route to handle the request. For example:
app.get('/example', (req, res) => {
const supabase = createClient(process.env.SUPABASE_URL, req.cookies['sb-access-token'])
...
})
@kangmingtay @alaister @soedirgo is this the "new" way to do this in supabase v2?
Seems a little odd, I have never seen clients which you need to create on each request, is this efficient?
@ydennisy yes, this is now the recommended approach for supabase-js v2.
Creating new clients is very lightweight, as there is no initial network request or anything like that. It's just a function call that instantiates a few classes :)
@alaister can you elaborate as to why this design choice was made - I have never seen any client used in such a fashion.
With all the issues we faced with v1 auth, and these new changes not looking hugely ergonomic it makes us consider moving away from supabase auth.
While I can't speak for the supabase team, I am fairly certain that this design choice was made to take full advantage of the industry-wide shift to serverless functions aka workers aka the edge. The new lightweight client seems a perfect fit for these new runtime environments.
Hi @ydennisy, could you elaborate on the issues you face with v1 auth? we would love to see if the changes we made for v2 auth helps to address those issues!
these new changes not looking hugely ergonomic
it would be great if you could elaborate on this point too - are these new changes not looking ergonomic because you've not seen other client libraries do this? or are you concerned about the changes from a performance efficiency POV?
hi @OverGreed, instead of creating a shared client on the backend, you should be creating a client on every route to handle the request. For example:
app.get('/example', (req, res) => { const supabase = createClient(process.env.SUPABASE_URL, req.cookies['sb-access-token']) ... })
I can't get this to work. User is logged in fine. I have a correct access token. But it throws an error like this:
{
message: 'Invalid API key',
hint: 'Double check your Supabase `anon` or `service_role` API key.'
}
Hi @ydennisy, could you elaborate on the issues you face with v1 auth? we would love to see if the changes we made for v2 auth helps to address those issues!
these new changes not looking hugely ergonomic
it would be great if you could elaborate on this point too - are these new changes not looking ergonomic because you've not seen other client libraries do this? or are you concerned about the changes from a performance efficiency POV?
@kangmingtay I can't speak for @ydennisy, but for me, creating clients everywhere makes me feel like Supabase is very tightly coupled to basically all of my application.
That's not great for me if I want to put all of my database calls in a specific chunk of code and then wrap them with some other interface for the rest of my application (in case, for example, something changes and I want to adjust to fit the new (external, e.g. Supabase) API without having to change many many pages).
@chrisb2244 what about having a module with a factory function that runs createClient
when you want to?
You configure it in a single file, then import a buildMyClient
function with no parameters, that actually executes the createClient
.
@JoaoCnh did you manage to resolve the "Invalid API key" issue?
Hi All - I'm seeing the same issue.Is there any further resolution on this?
Bug report
Describe the bug
When I try to use the client on the backend I am getting overriding of Authorization headers for auth.admin.* when using auth.getUser(token)
To Reproduce
I am creating a client with
export const client = createClient(apiUrl, serviceKey);
After that inside my application, I am getting the user by tokenand after that all the requests with an auth.admin will send the users token instead of as serviceKey
Expected behavior
Using of auth.getUser(token) should not override token for auth.admin.*