According to this, there’s no real difference between the two except for how persistent it is. <https//stackoverflow.com/questions/5523140/html5-local-storage-vs-session-storage>
I also saw that you get somewhere around 5-10MB per domain. Let’s say it’s 5MB. That means you have 5242880 bytes per domain. If you use 32-bit integers, you can store 5242880/4=1310720 32-bit integers per domain. Without optimizing anything, let’s say you use half of the ints for the episode number and half for the time location. This means you can have 1310720/2=655360 episodes. Even if you use a signed 32-bit int, you can store values up to 2147483647, which, if using seconds as your base unit, means you can store timestamps down to the second for >655k episodes that are up to around 68 years in length. You’d need to use some of that space to store a podcast key in addition to the episode number and timestamp. If you were going to store timestamps on every podcast you host then you might run out of space, but you only need to store timestamps for the episodes that the user has actually started playing, which will likely be <100.
So, I think you’re good on space and should choose whichever method offers the persistence you want. Personally, as a user, I think I’d prefer local storage.
writen by James Trimble
Better use local storage, so that it works after the user closes the tab.
James Trimble keep in minds that keys AND values in the session/local storages are always strings. So the integer-based math doesn’t work.
What I’d do is to use a ring buffer of sorts: store positions for the recent 100 episodes the user listened to. Adding one more means removing the oldest, so you only keep 100 timestamps at most.
Storage overflow is a real problem down the road, because catching an error on every .setItem in your code is impractical, but if you hit the limit, you’ll get an exception in any of those places at first and then in all of them. I’ve been there personally.
Mitigate by introducing limits like I described.
Another practical tool can be to introduce some dirty version of TTL for some of the data.
And every time the page loads, you can run a cleanup process. Because if I haven’t continued to listen to a given episode for, say, 60 days, I probably don’t care about that playback position anymore.
But try to keep it really stupid and simple, don’t try to invent a generic tool.
Keep in mind that, as long as you do all that in the browser’s storage, you will have other problems: • Hard to analyze without replicating it to your backend. • Hard to run data migrations e.g. when you decided to slightly change the schema of the underlying data (without purging the storage).
writen by Kirill Rogovoy
