Yesterday I wrote some general thoughts and experiences about rewriting code in reply to @Abraham Kim 's decision to start the rewrite of Adagia. As Writestreak has also gone through not one but soon three rewrites I thought I could open up those as well here.

In the beginning there was the holy trinity: the index.html, the main.js and the global.css

First iteration of Writestreak was written over a weekend. It could even be thought as a proof-of-concept rather than even a MVP. Anyway, it was already functional, feature complete on a sense that you could write posts, list- and read them, even leave a comment. But the codebase was crude: plain javascript, wild css and elementary html structures. Only sophisticated thing was the data handling, the use of Firebase SDK and realtime database. A single page that could fetch and post some text to the database directly.

I initially intended to use Next.js to build the proper version of the site. But after some Googling around I conducted that the Svelte was the next cool thing in web development. I had already chosen Firebase, which in itself is also rather cutting edge, so Svelte fit perfectly to the mix. I also ended up choosing Sapper for the actual framework that is built on Svelte. Nothing better than riding the wave every now and then, far from the corporate work with established and "stable" frameworks.

This phase introduced a lot of structure to both the codebase and to the site itself. No more single blobs of js, css or html. Instead pages got proper routing so it was possible to access them directly instead of loading them into same view. Code was also split into components. One for each route, one for navigation and own components for all the reusable elements like a post.

Having a framework in the mix meant I also had to do something for the deployment process. No more just uploading those files in the cloud. They needed to be built and compiled first. This was also a good time to add some initial linting and static code analysis to improve quality and ensure smooth releases.

After the code was nicely structured it was time to get back to the logic. After the previous rewrite it was all still happening on the frontend code. A lot of logic and processing making the pages heavier to load and operations slower to execute. So it was time for another split: move more intensive operations to the backend. This had also some security implications as now it was easier to manage the access rights. No more direct writes from the client side!

Having the backend/frontend separation allowed me to split the deployment process as well. Now, if there is changes to only either of them I can deploy just that part. For the backend the separation is even more granular as it's written entirely as serverless functions. That means there is a separate self-contained function for each action that can be deployed individually.

There is actually a third layer in my current architecture. Not everything happens on the backend function calls directly. The nice thing about Firebase databases is that in addition of being real time they are event driven. So I can trigger functions on any events happening on the database. So the functions callable from the frontend only do the minimum necessary to satisfy the users need. Everything else will be processed in another background function triggered by the events the called function might have had on the data.