This is Part Two of the story of my biggest project (so far). Read Part One here!
The app was finally ready (or so I thought), and the time came for it to be used during the Bay State Ballot Question Hackathon, an event hosted NECIR and WGBH in which participants would organize contribution reports for certain committees. That's where my app came in, as it would be the tool used to organize said reports. (The alternative was to just use spreadsheets, so really anything was better.)
So, I headed over to the WGBH studios, and until I reached the place I really had no idea what I was getting into. Upon arriving, I realized the location was the iconic building with the giant screen that I drove past countless times on my way into Boston. This is what I'm talking about. After settling in and making introductions, it was time for the app to be put in use.
Beta Test
As the event coordinator was demoing the app, he made the smart choice of introducing it as a beta test, something I hadn't considered as I (foolishly) believed everything would work as intended. Well, during the demo itself, the app encountered it's first failure.
The participants had been given a information sheet about the event, including the URL for the app. As one would expect, a decent amount of them tried making their accounts before the app was demoed. However, for some reason I still don't know (as of the time of this writing, Firebase support still has not answered my question), the account creation method firebase.auth().createUserWithEmailAndPassword(email, password) was being throttled, returning a auth/too-many-requests error. While the Firebase free tier supports up to 100 simultaneous connections to the realtime database, it would seem that it was unable to create just 30 accounts at once.
Well, that particular error made for an awkward start, as not only were about half of the events 50 or so participants unable to create an account at the start of the event, the event coordinator himself could not make an account during the demo.
Off to a Bad Start
If that wasn't bad enough, further issues arose when users started to receive reports that other users had already reviewed or were in the process of reviewing. This meant that the users viewing it the second time would not be able to make changes, and would end up wasting their time.
This particular error was not due to Firebase, but rather some poor design choices on my part. When I was first writing the app and believed I was working with a massive dataset, I designed it such that users would download the current version of the unreviewed reports' IDs when they loaded the app, and it would only update in very specific circumstances, or by reloading the page. This was to prevent users from having to download lots of data all the time, but this was no longer needed now that the dataset was significantly smaller. Unfortunately, I did not think about this before the event.
Initially, the participants tried reloading the page on their own, which achieved some minor success. However, I could tell that this not a desirable solution, based on the general vibes I was getting in the room. I spent the first 45 minutes or so frantically searching online and through my code, as I hadn't yet realized what the issue was. However, eventually I remembered that I had implemented a button that allowed users to resync their data with the current copy of the database.
Prior Planning Prevents Poor Performance
This fixed the issue for the most part, as users began to receive unreviewed reports and were able to actually make progress. And after about 40 minutes or so, those who hadn't been able to make an account earlier were able to. Although another minor error manifested in the form of some reports being marked "in use" although no one was viewing them, it was fixed by manually clearing that node on the database every now and then.
A little less than two hours after the event was started, all 3602 reports had been reviewed. The event was basically a success, as despite the almost catastrophic errors it encountered, it was announced as a beta version, and the rate at which it could organize data proved its potential.
Basically, this means I have the opportunity to fix the app and have it used again at the next event in October. So, I guess keep your eyes peeled for a Part Three?