Posts

In my last post, I mentioned that what makes an app local-first is its ability to keep running even when a connection falters. At first glance, this might look a lot like the offline-first movement that arose alongside the progressive enhancement wave of the mid to late 2010s. But there’s a subtle distinction. Offline-first apps focused primarily on staying functional during network interruptions but the server remained the primary data source. Data in this context is stored locally until a connection is restored, after which the locally stored data is deleted in favor of the remote store. A restored network connection progressively enhanced the experience and syncing only happened when there was new data created during the interim offline period to upload. ...

I’m frequently amused by how often local-first software gets mistaken for community initiated software. The ethos is spot on, but the confusion is revealing: cloud first has become the de facto standard for building apps. Local-first challenges this notion and subverts the dynamic between cloud and device. It puts the device at the center of operations. In this way, local-first apps remain operational despite an unstable connection unlike cloud-first ones. This of course doesn’t disregard the cloud completely. In a local-first model, the cloud shifts to the role of facilitator, ensuring data is synchronized across devices and sessions. ...

I’ve been pretty quiet about my work life lately. But spoiler alert, I have a job (and have been at it for the last 3 months)! If you spoke to me earlier this year or read a previous post about my job search, you’d have heard that the journey to a job post layoff for me was an emotional rollercoaster. Interviewing was not a strength of mine. I spent months getting wooed by companies impressed by my resume only to get rejected after yet another failed technical. It was horrifyingly depressing. But just as I was starting to lose steam, I got my break and landed a dream role, in the most unexpected (but unsurprising) of ways—in person, at a conference. ...

A few years ago, I received news of a professor’s passing in the most bizarrely impersonal way we tend to receive news these days: via a twitter mention from a college ex I hadn’t spoken to in years. The memorial service was set for that weekend in Central Massachusetts where he and his family lived. At the time, I was living in Cambridge, which was just a short train ride away. But I never made it past Back Bay. ...

I got laid off for the first time back in September (surprise!) and it took a giant toll on me emotionally. For the last 10 or so years I’d managed to muscle my way through engineering jobs despite not having a formal degree in CS. I’ve had the immense privilege of working at some really cool companies, working my way from the front of the frontend through the bowels of the stack and (for a brief moment) into the cold heart of bare metal. I’ve worked on product, systems, support tooling, growth/sales pipelines, billing, and miscellaneous developer workflows. In that time, I’ve written code in Ruby, JavaScript, TypeScript, Golang, Elixir and (some) Rust and worked with some crazy intelligent people. I’ve given talks internationally and written blog posts about various deeply technical pursuits. While I’m by no means an expert at all or many of things, I share this to say that I have a chunk of experience under my belt. ...

2024 was the year when I finally transitioned from surviving to thriving. With everything that transpired over the last few years, I got lost in the chaos of my reality and it’s taken me a second to “get back”. I’m not quite who I used to be, but I’ve become a version of myself that I’m quite pleased with, same same but different. The year came and went, for the most part, without incident. And (for once) I have no one to blame but myself for any and all shenanigans I found myself in. I grew, I learnt, and successfully averted any major crisis. In no specific order, here’s everything that happened this year in a nutshell: ...

Change is inevitable, especially so in applications that ebb and flow with system changes and user requirements. Generally, changes are codified in the form of an event; an event like a ddos attack for instance triggers a reaction or a response from one or more nodes, which ultimately mutates the overall state of the universe in a system. Undoubtedly, events rarely happen as one offs. At any given time, a sequence of events flows through the system. Whether it be a cascade of related events or multiple isolated events, the system is consistently responding and adapting. ...

Distributed nodes share neither memory nor a logical clock. In order to effectively keep a system in running order, nodes need some way to communicate with one another to share data and coordinate complex tasks. Interprocess communication (IPC) plays an integral role in this. IPC is the mechanism that enables a server to query a database instance and resolve a request with the associated data successfully. Without it, nodes remain stranded akin to the people in the Tower of Babel, connected by infrastructure but unable to communicate with one another. ...

In a distributed system, failures are to be expected. Whether it be a fault of the network or the node, failure is disruptive to the entire system. Failed processes struggle to recover and receive updates. Healthy nodes that try to connect to a failed node might fail completely or receive stale information, which can jeopardize the integrity and overall (C)onsistency of the system. To mitigate this, nodes have a failure mode, which it codifies in the form of a membership protocol. ...

In a distributed system, communication is crucial to ensuring no node becomes stale. Updates can happen in 2 main ways, through consensus, or through gossip. In a consensus model, nodes attempt to reach quorum by mutually agreeing on the order of updates or periodically voting on and rotating the leader in charge of distributing updates to fellow nodes—I covered the ins and outs of this in an earlier post, if you’re curious to learn more about it. Gossip is a concept analogous to consensus. It similarly keeps nodes updated except it achieves this via epidemic theory; If one node is infected, the entire population of nodes will eventually become infected. ...