Here are a few updates on what I’ve been working on in April for Chiffre.
I’ve been testing out status page SaaS, (what’s the plural of SaaS? SaaSes, SsaaS, SaaSs ??) for Chiffre, both to keep an eye on downtime (other than alerts in Sentry) and for transparency for users.
I ended up going for Instatus from Ali Salah, which is free for most features (you only pay to use your own domain, which I don’t think is a good idea for a status page, as last month’s Notion outage demonstrated).
It only works as a status page front-end though: a ping service is needed to monitor uptime/downtime and report. I went for UptimeRobot there, as it’s also free with good limits (5 minute ping intervals is probably much less than a one-man response time anyway), but I have my eye on Max Rozen‘s upcoming OnlineOrNot service, which seems to have extra reliability checks, and looks much better (aesthetics are important when in the middle of an outage). Plus bonus points for indie software.
🔗 The status page is available here: https://chiffre.instatus.com
Note: Instatus has an API to add public metrics to the status page, so I published the following:
Those metrics are updated every hour. Not yet fully #openstartup, but it’s getting there.
Having a status page is good, but how do I test that it works? I don’t really want to introduce downtime on purpose, but pushing back the testing to when there is actual downtime sounds much worse, so there might be a bit of planned maintenance to test out this system in the upcoming weekends. It might be possible to do this service-by-service to ensure no data is lost or uncollected. I’ll keep users updated by email in advance.
I’ve been testing some performance improvements, using streams to fetch encrypted data points.
I noticed that on very large traffic days (I had another blog post land on the Hacker News front page), fetching + decrypting still took a very long time, even though it all happens in a WebWorker now (so the UI is not blocked).
My current experiment is the following: instead of doing everything in one block (fetch all the data, and only then decrypt it all), I can stream messages from the server to the client, and have the client “react” to incoming messages by decrypting them as they come.
I initially started implementing the backend functionality using Node.js streams, but I recently learned about Server Sent Events (while contributing to Ali Salah’s Instatus Out service monitor), which could also be a good candidate.
In theory, this approach could even be parallelised by starting more WebWorkers, since there is no relationship between data points (they are ordered by timestamp in IndexedDB). But let’s not get ahead of ourselves. Measure, test, learn, implement, ship.
It led to a great quote, which is definitely going in the testimonials: 😅
“Loved you in Casino Royale”
– Brendan Eich
I will be having a chat with Boris Mann in a Fission Talk on Thursday April 29th about Chiffre, how it works under the hood, show a demo 😱 and talk about end-to-end encryption in general. You can register for the event, and I’ll follow-up on Twitter afterwards.
As a mise-en-bouche, here’s a simplified diagram of how Chiffre end-to-end encrypts analytics data points:
That’s all for today, I hope to see you after the talk.
Take care of yourself.
Founder | Chiffre.io