[Question]: Best practice when utilizing caching from service worker capabilities

[discoverlance-com]

I am working on an application that heavily uses service workers and caching. I want to know if there's any best practice or any api routes I should look to disable caching on. For my application, I am using a library serwist and it provides some very good fundamentals but I want to consider the api routes and network connections that this package will be making, what to skip caching and which ones should be ok to cache for say an hour.

I am presuming that I should not cache api routes like /api/login and /api/logout but I am not totally sure.

I know this might be a bit out of scope of this project but I am not exactly sure which api routes will be ok to cache and which ones will not be so I will really appreciate your help on this. I will also try myself to set up the package with my application and try some caching strategies to see which works but I might miss some important routes/information that will bite me in the foot later so I am hoping this issue will provide some useful insights into how the package works best with service workers and caching.

[awinogrodzki]

Hey @discoverlance-com,

Sounds like a really nice problem to solve!

I think you can safely cache /api/logout route as it's only purpose is to return empty headers. As long as cookieName does not change, this api route can be safely cached by Service Worker.

/api/login on the other hand requires an idToken. It can be cached, but it should always return different response based on the idToken. Ie. you should use the idToken as cache key.

You will most likely need to fetch that idToken using firebase/auth client SDK. Are you working on caching those requests in Service Worker as well?

[discoverlance-com]

Hey @discoverlance-com,

Sounds like a really nice problem to solve!

I think you can safely cache /api/logout route as it's only purpose is to return empty headers. As long as cookieName does not change, this api route can be safely cached by Service Worker.

/api/login on the other hand requires an idToken. It can be cached, but it should always return different response based on the idToken. Ie. you should use the idToken as cache key.

You will most likely need to fetch that idToken using firebase/auth client SDK. Are you working on caching those requests in Service Worker as well?

Hi, thanks for the reply.

Ideally, I don't want to cache any auth resources unless necessary and will have no effect on the functionality of the package or firebase. So yes, per what you have said about the logout api, I think I will go ahead to cache that but I think I will consider not caching the api/login route for now given it should be returning a different response or I will consider NetworkFirst caching mode which will try to first get new data, store the response in cache and will only use cache should the request fail.

What about api routes like the tokens api route for refreshing the tokens? Should I consider not caching that? Are these 3 api routes the only ones I need to consider or is there any other api route to consider? Thanks.

[awinogrodzki]

What about api routes like the tokens api route for refreshing the tokens?

This route is designed to give you the latest valid ID token to communicate with external services. In case of the lack of network connection, it will be called if the token is expired and you're using getValidIdToken function.

If you want it still to work when app is offline, you could cache it, but you'll also need to cache external API calls, if you have any.

or is there any other api route to consider?

No, it's only those three.

In general, it all depends on what you want to achieve – do you want the login functionality to work offline? It sounds weird, but could be achieved with Service Worker caching. Downside of that is the fact that service worker will keep the credentials, so if the app is offline and Firebase Client SDK calls are also cached, it may help bad actors to log in to the app.

/api/logout is safe to cache. Other paths – I would start without caching those and experiment how app behaves offline. If the credentials are valid, app technically could work offline for 1 hour without making a call to api routes

[discoverlance-com]

Sorry, I might have sent too many alerts. I was not sure of the guide to closing issues so I was a bit unsure whether I am to close it or you will. So I reopened it.

At the moment, I have the information I need as a result based on your reply so this case can be closed.