Caching and handling Indexeddb operations in Service Workers

[sharma-shanu]

Issue Link :- #54

This PR implements following features :-

1. Adds a new service worker for the web app (apps/web).
2. Uses worker thread to perform all indexeddb related ops.
3. Implements caching of images on the browser for faster load.
4. Implements analytics for user emails.

[vercel[bot]]

Someone is attempting to deploy a commit to the Inbox Zero Team on Vercel.

A member of the Team first needs to authorize it.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

:white_check_mark: elie222
:x: Shanu Sharma

---

Shanu Sharma seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sharma-shanu]

This also helps in removing complexity of indexeddb related transaction from core web application, so the web app can remain oblivious to the complexity of making and handling request network calls.

[elie222]

This also helps in removing complexity of indexeddb related transaction from core web application, so the web app can remain oblivious to the complexity of making and handling request network calls.

Great stuff. I see I've caused some merge conflicts.

What are the steps needed to push this to completion?

[sharma-shanu]

This also helps in removing complexity of indexeddb related transaction from core web application, so the web app can remain oblivious to the complexity of making and handling request network calls.

Great stuff. I see I've caused some merge conflicts.

What are the steps needed to push this to completion?

Hey Elie 👋🏻,

This is mostly done, I am ironing out some of the functionalities.

There are 2 features i want to add to this :-

1. During signup/initial login, when the user asks for stats, we load the data into tinybird in the background of next server, during this we currently show no data is available, while the data is being loaded in the background (this takes about a minute or two) . Currently, we have an iterative solution which is taking longer imo. I want to research on a solution in gmail api where we can make all the necessary requests simultaneously.


2. When a user logs out, I want to clear the indexeddb objectStores so that snooping is not available on stale emails.

[elie222]

1. During signup/initial login, when the user asks for stats, we load the data into tinybird in the background of next server, during this we currently show no data is available, while the data is being loaded in the background (this takes about a minute or two) . Currently, we have an iterative solution which is taking longer imo. I want to research on a solution in gmail api where we can make all the necessary requests simultaneously.

I agree this isn't great and needs fixing. But I'd keep it for another PR. I'd prefer to keep this one focused.

2. When a user logs out, I want to clear the indexeddb objectStores so that snooping is not available on stale emails.

Sure. I'm guessing this is a one liner in the log out function?

[sharma-shanu]

1. During signup/initial login, when the user asks for stats, we load the data into tinybird in the background of next server, during this we currently show no data is available, while the data is being loaded in the background (this takes about a minute or two) . Currently, we have an iterative solution which is taking longer imo. I want to research on a solution in gmail api where we can make all the necessary requests simultaneously.

I agree this isn't great and needs fixing. But I'd keep it for another PR. I'd prefer to keep this one focused.

2. When a user logs out, I want to clear the indexeddb objectStores so that snooping is not available on stale emails.

Sure. I'm guessing this is a one liner in the log out function?

Yes, it would be a one liner.

And i will create a separate PR for converting iterative solution.

[sharma-shanu]

https://github.com/elie222/inbox-zero/pull/97#pullrequestreview-1852227372

Hey @elie222 👋🏻, hope you are doing great.

I just made few changes to the sidenav and added labels section to it.

Here are screenshots for it:-

https://github.com/elie222/inbox-zero/assets/85648738/021e1901-886b-46ce-89a9-ddf5c2d3408a

When user has more than 4 labels, it will convert to expandable visibility toggle. Otherwise all options will be visible.

Let me know your opinion on how do they look and do they meet what you had in mind.

Thank you so much 😁.

[elie222]

How's it going here? I hope to add a better view for the mail client today/tomorrow. And that could be a helpful point to add a small PR for the labels only.

[sharma-shanu]

How's it going here? I hope to add a better view for the mail client today/tomorrow. And that could be a helpful point to add a small PR for the labels only.

Sure @elie222,

I have added the labels view to sidenav in this PR.

I saw the new changes on discord and they look nice.

I can create a small PR just for labels once the new view is up and merged.

[elie222]

Hey,

Went through a bunch of it right now. I didn't manage to cover everything. Would be really nice to have this broken out into separate PRs. Would be easier to merge that way. Because it covers a lot of functionality right now.

When testing the app locally, I didn't notice any speed improvements. Should I have seen instant loading of labels in the sidebar for example?