Last year I mentioned how some small dynamic parts of my main website - Myhro.info - were migrated to Cloudflare Workers. This time I did a similar move, but instead of migrating just a couple parts, I moved a whole webapp, including both backend and frontend, to there. Before mentioning how much better Cloudflare Workers are one and a half years later - and they already rocked in the first time! - let’s go through all the iterations “Tem Água Hoje?”, a website created to better inform people about water distribution restrictions, went through its lifetime.

Debut

The first iteration of the website came in form of an all-JavaScript application running in the browser. Literally everything was JavaScript in one form or another: the frontend, parser and even the database itself was structured in a JSON format. This happened for two reasons: first, I wanted to practice a bit of JavaScript. The second reason - and maybe the most import one - is that in this way, there was no backend whatsoever, no server-side part which I would have to worry about. The whole webapp was served as a static site straight from S3, which absurdly simplified its deployment and maintenance.

This version was good enough for the start. It was a bit annoying to generate the database dump, as I had to manually go to the browser and save it as a file, but as the water restrictions were lifted less than two months after starting the project, I wasn’t worried about it anymore. Then in the beginning of November this year, it was announced that water restrictions would be again in place for the next months. I had to decide to either just feed the new data to the webapp or rewrite a good chunk of it.

Component decoupling

Being a full-time Go programmer for a while made me biased towards rewriting the parser in Go and separating the actual logic about the water availability from the frontend, moving it to a real backend. With a bit of Gin - my favourite web framework - and SQLite, I was able to offer a REST API, powered by a small-but-full-featured relational database. The result was nice and delightful to build. All of that while teaching my nephew, who is studying Informatics, about all these components and how they play along together at the same time - a win-win for both him and me.

I really liked the result: a vanilla JavaScript frontend, fetching information from a Go API, backed by SQLite. There was just one problem: I would still have to deploy, host, maintain and care about the backend availability - otherwise the whole webapp would become useless. It was hosted in a server that I use as a developer workstation from time to time, but that was too fragile. I contemplated deploying it to a Kubernetes cluster, but that would be too much. I had to find a better and easier - preferable cheaper - alternative.

Workers to the rescue

As I mentioned, Cloudflare Workers have evolved considerably after its launch. I’ve been following the new features being offered, but wasn’t playing with them - something which bothered me a bit, as I’m in love for the platform since day one. This seemed like a perfect opportunity for me to try new things out, like their key-value store, Workers KV. By being a somewhat limited storage solution, as literally only string keys and values are available, I had to come up with a new modeling for the database, as no relational features like columns or queries would be available.

To be honest, I actually liked the limitations. There’s beauty in how simple the environment is, where one can use basically one language - JavaScript, if you don’t consider the WebAssembly option - and what is almost literally a hash table as storage layer. In the end, that actually simplified the logic to check for water interruption intervals, without forcing us to get back to the first JSON-based database format - which wouldn’t be supported anyway, as it wasn’t based only in strings.

Bonus points and conclusion

One interesting thing is that Cloudflare Workers can now also host static files in the form of Cloudflare Workers Sites - although not literally. What they do is to offer some logic to store file contents as strings in the KV store and fetch them from HTTP requests. A really clever usage of two simple features that can be used together to form a new one. By also deploying the frontend to Cloudflare Workers, S3 wasn’t needed anymore at all, simplifying the infrastructure and deployment procedures even further.

So, now we have temagua.myhro.info in a much more simple, faster, resilient - and also cheap - platform. I don’t have to care about it being up and running all the time - there are way more competent Engineers at Cloudflare doing that for me. And, by being free from the maintenance hassle, I was able to invest time in much more interesting things, like porting the frontend to React, something I did for the first time in my life.

Keep rocking, Cloudflare!