This week brought two major milestones: evolving our reactive UI system from basic polling to real-time change notifications, and tackling a tricky QR code authentication issue during a live event that taught me valuable lessons about debugging and secret key handling.
Moving Beyond Polling
When I first added reactive UI updates, I went with the simplest option: polling CouchDB every few seconds. The app would check its update_seq, and if something had changed, it would refetch the data. It worked, but it wasn’t great. Requests kept firing even when nothing changed, and updates only showed up after the next interval.
This week, I discovered CouchDB’s change notification feed. With Wilt’s startChangeNotification, the app can subscribe to a real-time stream of changes directly from the database. Instead of guessing, CouchDB tells us when something happens. The difference is clear:
- Far fewer wasted calls
- Updates appear instantly
- The overall experience feels smoother
Looking back, polling did its job, but change notifications just feel like the proper solution. Sometimes the “good enough” version really is just a stepping stone.
Extending and Refactoring
I also extended the polling mechanism to other roles this week and added tests around it. Since more parts of the codebase will share the same structure, I decided to factorize the logic using Flutter’s mixin feature. They turned out to be a nice way to reuse code without building messy class hierarchies.
QR Code Troubles in a Live Event
Outside of development, I was also on-site again as server standby. This time, we tried using the new QR code scanner for attendance in a live event, and it didn’t go smoothly.
- At first, scanning just… failed. No error message, nothing. After digging, I realized I had only written error handling for the Usher role, not the Bouncer. A small oversight, but it caused a lot of confusion on the ground.
- After fixing that, scans still came back as “INVALID QR,” even for valid codes. Hours of debugging later, I found that disabling secret key verification made it work, so the issue clearly lies with how the secret key is being handled. My supervisor suspects something is going wrong in the encoding/decoding process and I’m now digging deeper into that suspicion.
It was frustrating in the moment, but I walked away with a key lesson: sometimes it’s not the big new features that trip you up, it’s the small details you assumed were fine.
Reflections & Insights
- Polling was fine for a start, but change notifications are what make the app truly real-time.
- Mixins are a tidy way to share logic without overengineering.
- Error handling is not optional, missing messages can cause just as much chaos as the bug itself.
- Secret key verification is still my top blocker, and I need to dig deeper into encoding issues.
What’s Coming Up
Next week I’ll continue fleshing out tests across other roles and modules, while also taking a closer look at the secret key issue. Debugging crypto errors may not sound glamorous, but it’s the kind of detail that decides whether the system actually holds up under pressure.
0 Comments