The local-first vs. RESTful calculation
So, is all of this configuration and newfangled code worth it?
If you are building a simple dashboard or a form-based application, the traditional JSON API (REST or GraphQL) approach is still king. In those models, the server is the single source of truth, and the client is just a dumb terminal. It is simple, stateless, and easy to debug. It’s also familiar.
But that simplicity comes with an unavoidable latency cost. Every interaction requires a round-trip ticket to the server. If the network hiccups, your app freezes. JSON APIs force you to manage loading states, error boundaries, and optimistic UI rollbacks manually.
Local-first flips the calculation. You pay a higher cost up front: you have to define a schema, manage a local database, and think about syncing rules. But in exchange, you get an application that feels like a native piece of software. Local-first creates data continuity, the ability to walk out of Wi-Fi range, keep working, and have your data follow you across devices when you reconnect.
Architecturally, we used three major components: the database, the syncing engine, and the client. This is actually similar to your conventional RESTful stack. In the local-first structure, the syncing engine takes the place of the JSON API server. In short, you have a similar amount of high-level complexity, but with different actors on the ground.
Local-first architecture is a fascinating development for JavaScript and the web in general. There is a huge inertial mass of JSON APIs to overcome, but here is a real countercurrent. Local-first may never rise to the level of adoption of RESTful architecture, but local-first data and reactive SQL constitute one of the most important trends to be watching closely right now.
