Browserboard Blog

Over the past two weeks, I've put down feature development to focus on stability and programmer-oriented features. To users, this means fewer bugs and better site performance in the future.

(In case you missed the last one, which didn't go out via email: Browserboard Update: Sharing Options and Heaps of Bug Fixes)

API

Someone contacted me about embedding Browserboard in a web app that lets children draw on storybooks. It sounded neat, so I built a simple API to enable them to do that. The API isn't public yet, but if you send me an email or use the contact form, I'll give you access and send you some documentation.

Error tracking

It's important for a web developer to know when things are going wrong. To that end, I finally integrated Sentry into the frontend JavaScript. This revealed a handful of bugs I quickly fixed.

This integration increases the amount of information tracked about users, but none of it is tied to anyone's information; all I know is what tool an anonymous person was using when they experienced an error.

Page load times

When I introduced image thumbnails for logged-in users, I used very simple, sub-optimal code on the backend. If multiple users were uploading thumbnails at once, and my image host decided to take a long time, it could cause the whole site to hang.

I ended up switching image hosting providers from Backblaze B2 to Digital Ocean Spaces, and thumbnail uploading no longer goes through my server, so the whole site should be more consistently responsive.

The most important result here is I can continue to spend very little on servers, which is good because I'm paying out of pocket to run this site for free. Another important result is I can build an image upload feature and be confident it won't bring down the site when I release it.

Continuous Integration

When you make changes to software, there's always a risk you introduce a bug. You can test everything by hand before every site update, but that takes a long time and there's a chance you miss something and break a feature for users.

People usually solve this problem by writing automated tests and running them as often as possible. I avoided this for a long time because I've been making big changes quickly, but this weekend I finally got test suites running for all the important parts of the app using GitHub Actions.