https://supertokens.com/
Join Discord
Menu
Home
Archive
Is there any sort of thing like a "best practice audit?" I feel like we're (still) regularly encount...
# support-questions-legacy
m
Is there any sort of thing like a "best practice audit?" I feel like we're (still) regularly encountering major issues with SuperTokens slowing down our Next.js application (far more than I ever experienced with Auth0 before) and the performance is really a problem.
A lot of the time we end up with infinite loops of logging in and out.
I'd like to switch from cookie-based auth entirely. It's not reliable, especially when we want to do things like use Vercel preview domains.
r
hey @Morgante Pell we have non cookie based auth which we have released in the latest versions of the frontend and backend SDKs. Maybe try that out.
In terms of the app slow down, that's unexpected - maybe you can give us more information about where the slowdown is coming from?
m
I'll give it a shot.
One thing I'm not clear on is why do we make an API request when clicking "log in with GitHub" - https://api2.grit.io/auth/authorisationurl?thirdPartyId=github
This seems like an unnecessary round trip that should be (a) not needed at all or (b) pre-loaded before the user clicks log in
r
well, we allow you to define scopes etc only on the backend. So that's why. But if you want, you can override that function on the frontend and just return the intended URL directly.
@Morgante Pell during update, please be sure to checkout our changelog which you can find in the github repo of the SDKs that you use.
m
Yeah, I'm taking a look at that.
What about pre-loading the URL when the user first hits the page? Your reasoning makes sense, but ideally we’d want to minimize round trips by default.
For context, it adds about 1s to our login flow right now. I’m happy to do the workaround you suggested.
Definitely appreciate the flexibility here btw. I’m confident that we can find a fix.
r
Pre loading would also require one api call? Or am I misunderstanding you?
Also, 1s to make that query seems rather high. How are you running your backend?
m
Yes, but it would be a background query not in the user flow. So no delay for users.
Node on Cloud Run. We’ve had some usage spikes that are slowing things down.
r
Yea, fair point. But the downside would be that this api call would be made for everyone who ever visits the login page - even if they don’t sign in or use email password to sign in. But either way, if the scopes etc don’t change, it’s best to just override on the frontend and return the string directly.
This is serverless correct? Do the functions remain warm if queried? And for how long do they remain warm?
m
I’d assume that a high enough percent of people visiting the login page are logging in that it’s worth doing.
Of course happy to hard code, just trying to avoid maintaining code in two places.
Yes, they do stay warm but when traffic is spiking it’s a lot of cold starts. I might want to carve auth into a different service.
r
Yea. Cold start will cause slowdowns. Cause it fetches the public keys for session verification on server start
You could override the frontend function that fetches this URL to cache it. And then on page load, call the function to get the url so that when the button is pressed, it gets it from the cache. This way, you won’t need to hardcode the url on the frontend.
m
Yeah I mean, I'm happy to just hard code it anyways. I'd just suggest thinking about the built-in behavior a bit more. Even if the request is faster (100-300ms), every delay during a login experience has some impact.
r
Makes sense. We could open an issue about this on our GitHub and we can add it to our roadmap
m
Thanks for being responsive
r
Thanks! Appreciate the idea for this issue. Will add it to our roadmap
100 Views
PreviousNext
Powered by

SuperTokens.com

SuperTokens is an open source authentication solution offering features like: Different types of login: Email / password, Passwordless (OTP or Magic link based).

Powered by