| Source | https://www.youtube.com/watch?v=uWephkIzFoY |
|---|---|
| Readwise URL | https://read.readwise.io/read/01kvyrvqrtan2q2wdtqtprh87p |
| Readwise ID | 01kvyrvqrtan2q2wdtqtprh87p |
| Date | 2024-09-30 |
| Author | Chris Raroque |
| Category | video |
| Cover image | https://i.ytimg.com/vi/uWephkIzFoY/sddefault.jpg |
welcome to the Vlog if you’re new here my name is Chris and I build productivity apps I usually focus on one productivity app per video So today we’re focusing on Ellie quick context Ellie is a daily planning app it’s basically your to-do list and calendar combined if you’re someone that likes to plan and time box your day you should go check it out but that’s the app that we’re going to be talking about today so I use Ellie on a daily basis I actually can’t function without this app to be honest but one of the areas that I think can be improved is the calendar functionality of the app in my opinion Ellie is primarily a to-do list application and then a calendar second and because of that I haven’t really put too much time on the calendar side of
things but I do want that to change as I was looking at the calendar of Ellie I was thinking okay how can I improve this I started looking at other calendars on the market like Apple calendar and notion calendar one thing that stood out to me was these apps are really fast the minute I open the app the calendar events load instantly but when you open up Ellie the calendar events take like five and sometimes even 10 seconds to load so speed is an area I haven’t really looked at and I thought to myself this would be a great first step in really improving and getting Ellie to the level of these other calendars setting a good foundation making it really fast in performance so that’s the problem and that’s what decided to work
on in the last week that’s what this video is going to be about I’m going to take you guys through the speed improvements that I made I’m going to show you guys some of the stuff I learned we’re going to walk through some code and this is going to be a little bit more technical than the videos I usually post so let me know in the comments if you have any feedback on that and if you guys like it I’ll post more videos like this so yeah this is what we’re going to be covering today okay so very summarized the problem is Ellie loads very slowly a lot of the other calendar apps load very quickly so the way Ellie works is when you load up the app I have to go and fetch the calendar events directly from my server every single time and in some cases that can take up to like 10 seconds to load
the calendar events but what happens is when someone loads the app it’s just a blank calendar and then there’s like a little spinning icon that shows hey we’re loading events which some people don’t even realize that that thing is spinning and then after a 5 to 10 seconds the calendar events load which obviously is not great and what’s worse is that every time you start moving in the calendar like if you go to the next week that’s another 5 to 10 seconds to load the next set of calendar events if you change which calendar you’re looking at that’s another 5 to 10 seconds to reload that stuff it might not seem like a big deal but I feel like for something like a calendar where your constantly
moving you’re constantly changing calendars this will start adding up over time and does make for a really bad experience so something I noticed in other apps so let’s take notion calendar for example is that they load instantly when I’m tabbing between Pages or when I’m changing calendars I notice that they load extremely quickly so that’s the standard that I want to hit for Ellie I want these calendar events to load near instantly and that’s what I mean when I say I want to improve the performance of the app cuz again performance can mean a hundred different things it could mean that the app in general is faster it can mean that certain actions are faster but in this case it means that the calendar events load much much faster that’s the kind of
performance that I want to achieve here okay so let’s talk about the solution first thing I did was study how some of the other calendar apps in the market work because a lot of these calendar apps have teams behind them that have thought really hard on how to optimize performance so if I don’t have to reinvent the wheel I won’t so the first thing I did was I picked one of the calendar apps to look at and study and that app was actually notion calendar and the reason I chose notion calendar is because if you didn’t know notion calendar actually used to be an app called Kon when Kon first came out it was known for its blazing fast performance its really good design and I’m pretty confident that the team
behind it put a lot of thought into the speed of the app so if anyone did it correctly it was the KRON team which is now the notion calendar team the second reason that I chose to study them is they actually have a web version it’s pretty easy to take it apart and look under the hood so that’s a huge reason that I chose them a lot of apps actually leverage this thing called index DB which is basically like a local database that lives in your browser it’s very lightweight though so you can’t really store complex data here it’s very commonly used for stuff like caching and which in this case that’s what this is we’re just kind of caching calendar events so they could be pulled up faster
and after digging the notion calendar it does look like that’s what they’re using in Chrome you go to this application Tab and you can actually see index DB here you can do this for any web app and you can see what is being stored on your browser they’re basically storing a copy of all the calendar events and some other data in index DB I decided to also test this because whenever I cleared index DB and reloaded the app it didn’t load instantly and then when index DB is full of data it does load instantly so I have some pretty high confidence that this is how they’re actually storing things locally and caching it so after looking at indexdb and then a couple of other Sol Solutions like local storage
or SQL light this is probably the technology I should use to solve this problem that was the research phase once I figured this out and I was like okay this is the right path then I started working on actually implementing the solution fair warning I’m not an expert in any way on this stuff I actually just learned indexdb basically in the last week absolutely feel free to correct me in the comment section so a little context on the technology Ellie’s a react app even the desktop version is technically a react app it’s just wrapped with something called electron the underlying technology is react and I use this thing called Redux for State Management I’m not going to try to explain Redux here but basically just
know that it manages the state of my application this is basically how components can pull data and talk to each other so my calendar can talk to my list can talk to my combon they’re all talking and it’s all synced through Redux whenever I want to pull calendar events I have this function in Redux that pulls events from my server it’s made up of a bunch of sub functions to fetch specific calendars from the server so there’s a Google one an Outlook one and an apple one let’s take a look at the Google one all it’s doing is literally calling my server getting the events and then returning it this looks kind of complex but it is very simple some of this is just the Syntax for
Redux that’s just how you write it at the heart all it’s doing is pulling from the server and then storing it in Redux so that my application can use it so my highle plan to do the caching is let’s pull from the cash first while we’re waiting for the server to return stuff then the second part of this is when the server Returns the fresh data let’s go use that fresh data and let’s also update index DB with that fresh data it’s a two-step process let’s load from the cach when the data comes in let’s go update the cash very very simple I’m sure there’s a better way to do this this is the basic Bally the structure
that I decided to follow the hard part was actually the second part which was when we get fresh data from the server let’s go update index DB with that fresh data and it sounds really simple when you get fresh data go update index DB with that data but here are two things that I ran into with this when I’m pulling data from my server it’s usually filtered I don’t just pull all calendar events from Google because hey Google won’t allow that but that’s also very expensive to do there could be tens of thousands of calendar event so you usually have a filter on this and it’s usually a timebase filter so it’s like just give me calendar events between you
know Monday through next Monday or it’s filtered on what calendar I’m actively looking at so if I’m looking at my calendar and then maybe I’m looking at someone else’s calendar I’m then filtering on both of those calendars and the time range there’s a lot of filtering going on when I’m pulling from my server so if I decided to just override index DB with the data coming in then the issue is I might accidentally wipe some data that’s not included in that filter to show you an example let’s say that I have a month’s worth of data loaded in index DB and then I decide to pull from my server just this week’s worth of data when I
pull that week’s worth of data and then override index DB I basically wipe potentially weeks worth of data from the last 3 weeks I needed to find a solution that will let me just update that portion of index DB this actually took a lot of trial and error to figure out the solution seems so simple now in hindsight but it did take me some time to get here so the first thing I do was I actually run the same filter on index DB so I pull it based on a specific time range or specific calendars and it’ll return like 15 calendar events then I pull from my server which again has the
same filters and it loads 15 calendar events so now I have events from indexdb with these given filters and I have events from my server for these given filters and then I iterate through this list of events then I do a couple checks so if the event is in index DB but it’s not in the server that means that it was probably deleted so I go ahead and delete that from index DB and if it does exist in index DB then I update it with the version that just came from the server so now it’s up to date so that solves our problem and then we get to keep all the old data so if you have months worth of data loaded or a bunch
of other calendars loaded those remain untouched only the relevant portion is updated so again this sounds really simple but it took me a long time to figure out I tested like three or four other things before I came to this really simple solution and so far it’s working so I don’t see any problems with this but if you notice anything definitely let me know and so again this is the code that goes and updates and refreshes index DB with that portion of events that we just pulled from the server and I had to rewrite this two other times because I needed to do it for Outlook and I need to do it for Apple but basically they follow the same type of structure and here’s the portion of the code where I actually fetch from index index DV before we hit the server
and again it had to be duplicated three times because outlooking Apple so the final result is we now pull from index DB while we’re waiting for the server to respond with the fresh data and so the result is near instant loading if the event has been loaded before if the event has never been loaded before there is still that waiting period but for events that have been loaded it’s near instant if you start moving between the weeks and again it’s stuff that you’ve already seen so if you start moving into the past these events should load instantly and this concept of loading from the cash and then the network and storing an indexdb this can be used for
basically everything I actually decided to use it to load the actual calendars themselves so when you click this button there’s a drop down of all your available calendars I had to pull the fresh data from the network every single time so that took like 2 to 3 seconds to load but now we’re storing everything in index DB you don’t have to wait anymore it loads instantly and then again we get fresh data and then we update it so these little improvements to speed in certain areas of the app I think they do actually add up and you can apply this technique to everywhere so I plan on doing the same thing for loading the lists on the sidebar I actually plan on doing it to load Le tasks so all the tasks should be loading instantly user settings should loan instantly I’m going
to monitor the results of this calendar Improvement and if everything goes well and I didn’t miss anything I’ll be adding caching to basically every portion of the app so let me talk about some of the things I ran into that are interesting to call out so one of the things that kind of caught me off guard was indexdb has a versioning schema I’m coming from the world of Firebase and no SQL databases where there really is no schema so for indexb this was slightly more complicated not too bad but every time you change the schema you have to upgrade the version number so that way it knows okay what version are you on then you can write an upgrade function which then will help you migrate the
user data to the new schema it was a little Annoying at first during development because I was constantly changing the schema but I got used to it and in hindsight does give me some peace of mind that when I do make changes I can just migrate users over and have a lot more control over that if you come from the SQL world or use something like super base probably not knew it all but for me that was a little bit of an annoyance and there was a lot of crashing going on because I didn’t understand how the schemas worked so that part got me another thing I ran into was I have to be really careful because I kept storing corrupted data so for example when I was pulling the calendar accounts from my server my server actually crashed and returned an
error and I accidentally stored that error message in index DB instead of my Outlook calendars and so the entire application was crashing because of that that really freaked me out cuz then I realized oh man if I mess this up it’s going to be way harder to debug on users machines basically the stakes are a little bit higher here now that I’m doing local caching and storing data locally where if I store corrupted data or something goes wrong it’s just a little harder to correct than usual to combat this so I thoroughly tested this thing and I actually did add a button in the settings where when you click it
it’ll completely clear indextv if there’s an issue where like somehow it’s saved corrupted data they can click the button and just wipe it so hopefully that’ll buy me some time I also added a little bit more robust error handling before the error messages were super generic and just said something went wrong please contact support now they say that but they also give a little bit more descriptive of an error message whenever someone contacts me I’ll have a little bit higher chance to know is this an index DB problem or is this something else and then I can troubleshoot a little bit better so that was something I did to try to make debugging a little bit easier because these bugs will be
really challenging when they come up so that was a second thing that I really ran into in the process of redoing this I made a ton of other performance changes there was another bug which was like a race condition where when you drag a task then you move it really quickly it’ll glitch and then hop back to the first place and then correct and go back to where it was since I had a chance to kind of go in and relook at this code which a lot of this was written like a year ago I had a chance to correct some of these things so overall not just the speed performance there was actually a lot of stability changes that came with the update I released this week overall major Improvement for this feature there’s still a lot of things I can improve like
when I look at notion calendar it opens still near instantly and mine although a lot faster it’s not really near instant I have an idea of how I can improve this stuff but I’ve decided this is good enough I’ll save that for later in a future improvements I plan on also taking the exact same technique and applying it to the IOS app but instead of indexdb I’ll probably be using something like core data most platforms do support something like an index DB for caching so if you have an application highly recommend checking that out but I’ll be applying it to the IOS app for sure but yeah that’s the big performance update that I’ve been working on in the last week had a lot of lot of fun learning index TV I think
I’ll be using this for a lot of features and all my other applications moving forward so this was really really fun for me to learn and I wanted to share this with you guys so hopefully you guys found this interesting and if you like this kind of content definitely check out my Instagram and Tik Tok I post almost every other day about pulling productivity apps and obviously if you like this content don’t forget to subscribe but thank you guys so much for watching and I’ll see you guys in the next video