Auth optimisation strategies

Get Help and Help Others
1

Hi there,
I’m using dbAuth and Vercel for my application.
I’ve noticed that the authentication requests are likely to be the first bottleneck to my application (I guess the slew of 3rd party auth options for this issue should have tipped me off sooner).

My application uses a layout that includes some useAuth functions/state variables.
As a result, each page change results in call to the auth endpoints of my serverless deployment.

I’m curious if this is necessarily a consequence of dbAuth, or if there are any low hanging auth optimisation strategies that might extend the life/performance of my application with its current auth architecture.

Specifically, I’m wondering if calling useAuth once in the root of the application into a context variable, and then consuming it from context across the rest of my application will have any effect? Or will memoisation have any effect?

TLDR: Redwood specific Auth/dbAuth optimisation strategies. Does an API call get made each time useAuth is called?

2

Hi @littletuna4,

An API call should not be made for each useAuth call, but one will be made for each fresh render i.e. when you refresh the page, or go to a URL. This is effectively to restore the auth state, because on a fresh render the validation has to happen on the server, and it has to receive the current user from the server.

When you say “each page change” - do you mean when you are opening in a new tab or perhaps refreshing the page? It could be that its a case of how you’re trying to debug this!

After you land on the page, and your Redwood app has been initalised, when navigating normally i.e. using client side navigation, which is 99% of the time, the calls to server are no longer made.

Specifically, I’m wondering if calling useAuth once in the root of the application into a context variable, and then consuming it from context across the rest of my application will have any effect? Or will memoisation have any effect?

This is already the case :slight_smile: - you wouldn’t achieve any benefits from reimplementing this!

Thanks,
Danny

1 Like
3

Ok great, thanks for your reply,
So, may I ask, what does the loading variable indicate specifically from useAuth? Each time I navigate in app, this toggles to true for a little bit.

Based on your advice and some research on how how SPAs handle navigate/anchor tags. One action I’ve taken i’ve taken on my app it is to:
preferentially use button elements with onClick={()=>navigate(routes.something()} instead of a elements with href={routes.something()}.
(It’s basic, but I only just learnt that this method prevents page reloads)

4

So, may I ask, what does the loading variable indicate specifically from useAuth? Each time I navigate in app, this toggles to true for a little bit.

It indicates that the authState is being loaded. i.e. the server hasn’t validated and responded with the currentUser just yet!

preferentially use button elements

Yep yep! You definitely want to do this.You can also use the built in Link element. I’d recommand doing a quick skim of the tutorial to see what’s available :slight_smile: