getClaims in a serverless enviroment not yielding performance gains
Hello, I am using vercel to host my SSR app that uses Supabase. Switching to the getClaims instead of getUser does not yield any performance gains at all. Everything is the same approximately.
Am I doing something wrong, or is it because of the serverless environment? Please note that the authentication happens on my sveltekit server and the session is sent over to the client.
I have watched the whole tutorial video and read the blog post and followed them step by step, and all is working correct just that there are no performance gains.
17 Replies
Might seem like a stupid question, but I wanna make sure: is the project using asymmetric JWTs?
yes the new asymmetric JWts
released in launch week 15
I know that if
crypto.subtle isn't available in the env then you will experience this. I just don't know what environments that would be.
A quick glance at Vercel's docs show that's available in the node and edge runtime environments though.
I'm guessing a new server client is getting created for each server request, which will likely nullify any local caching the supabase client tries to do, but the Supabase global cache should still be kicking in and reducing latency for the .well-known/jwks.json lookups.
The only other thing I can think of is if the JWT is expired when it reaches the server, then it'll get refreshed, causing a request back to your Supabase instance.
There are a few other subtleties, but if you're using asym JWTs, I doubt they'll be an issue.So what is the solution then?
Are you seeing the perff gains when developing locally?
locally i still am using symmetric keys, I did not know how to switch to asymmetric keys
Can you show any of the relevant code? Mostly, are you doing any other auth-related supabase calls on the server side - beside login/logout?
I dont' think it's relevant since the code is actually working, and the jwt is asymmetric, I checked the headers and all is fine. I guess this is because of the serverless environment. What do you think?
For each server request (each page) I am getting the session (which is not safe) first to see if there is one, then if there is, it means the user is logged in, so I call getClaims (safe) to get user data (previously auth.getUser). I am timing both getSession and getClaims to see if there was any change in the performance. getClaims is approximately the same as getUser in terms of processing time.
If there is a performance gain it comes from not making a full trip to the Supabase auth server. With getClaims, if the session is not expired then it should worst case hit the .well-known/jwks.json end point which is CDN cached so should be 10's of msec instead of 100's.
Can you see your network requests in your environment?
The one thing I'd recommend here is to do
getClaims(session.access_token). It may not make a ton of difference, but getClaims will call getSession internally if a JWT is not passed to it; so, since you're already calling it (I do the same thing), you might as well pass in the JWT to getClaims to save a storage check.@garyaustin thank you. To better understand, where is this endpoint? Should it be on my api server (using sveltekit)? how is it populated?
@j4 will try it tomorrow
It is a supabase endpoint. getClaims will call it.
Ohh great thanks. Is there a suggested way to see network requests?
However you do that in your SvelteKit server side environment. I don't do server side stuff so just use the browser dev console.
yes this is why I cannot use the console to view the network requests. I Will figure out another way
@garyaustin you mentioned you don't do server side stuff, we'll I am just curious to know what are the pros to that from your opinion
Well I don't do next.js/sveleteKit with server side. I've done serverside stuff before with PHP. The reason I don't is the main app that got me to Supabase was using Firebase and it runs as a SvelteKit PWA and needs to work off line. So there is no server for basic app operations involving auth at least.
oooh ok. nice.