Why You Should Care about Local First

Recently, when trying to implement realtime sync for my startup

, I fell into a rabbit hole and stumbled upon this concept of building local first apps.

Building local first means to build an app (or website) that can run without an internet connection, at least temporarily. The syncing will definitely need internet connection, however the usual navigation and other functionalities of the app should not be dependent on internet. In fact, the only thing the internet connection should do is sync the local state with the database.

The most popular example of a web app following this is Linear, the project management tool. Figma also falls within this paradigm as after the initial load of a file, it is offline-ready.

If you look at the recent changes of React and Next, they seem to be pushing towards a server heavy implementation. The local first approach goes in the entirely opposite direction and preaches for a heavy client. The clients fetch all the necessary data and stores them locally on the browser, and later through a sync engine running on the client side, it ensures that the data is in sync.

Advantages of Building Local First

There are some unique benefits building local first brings that aren't obvious at first:

1. No Loading Spinner

   Whenever you make a change, you don't have to wait for your server to acknowledge that change before you show the effects on the UI. This is a bit like optimistic updates but it's built-in and doesn't require writing any extra code to achieve this functionality. So every time the user takes an action for anything in the app, the changes are instant and makes the app feel blazing fast.

   
   

2. Offline Support

   Most cloud platforms aren't supposed to be used offline. Linear isn't supposed to be used offline either. However, having the option to use it without any restrictions even when you are in a plane ride or have a bad internet connection in general, would make the experience more pleasant for your users.

   
   

3. Realtime Support is Built-in

   Once you build your app on top of a sync engine, you don't have to write any logic to implement realtime. Every time something changes in your UI, you update your local DB and the sync engine will sync it with the server. And the same will happen the other way around, when someone else makes any change in their UI, their sync engine will sync it with the server and then server will send updates to your sync and the change will appear on your UI.

   

4. Improves DX

   This is probably the most underrated advantage of building an app with a sync engine. It improves the developer experience tremendously. You don't have to trust me on this, listen to Linear's CTO talk about this. There are a few ways going local first helps with this:

   1. Never Write Network Code: When building the UI, you never have to write network code again. This is a massive win because network calls can get very messy and sometimes annoying to debug as well.

   2. Never Write Optimistic Update Code: You don't have to write code to implement optimistic updates either. Those are also handled automatically with the sync engine.

   3. Never Manage Cache: Managing cache can get quite messy. Sometimes you might use different caching strategies on different part of the UI and end up with 2 versions of the exact some object on 2 different palces. This problem doesn't exist anymore when using a sync engine because you're no longer creating a cache, but rather you're just creating a local replica of the database.

   4. Ignore the Backend: Prototyping is fast because you can kind of ignore the existence of a backend and create the features on the frontend without writing any temporary code. As long as it's a single player feature, you can just flag certain as local-only and once the feature is complete just start syncing it and you're feature is ready. This should drastically improve the speed of building new features.

Disadvantages of Building Local First

Just like all other things, this also comes with some drawbacks.

1. Still Pretty New

   This is not a new concept, but it has been gaining popularity only recently. So, there aren't too many options to choose from if you want an existing solution to help you integrate this into your app. This is especially true if you don't want to use specialized databases for this purpose and want to stick to the usual PostgreSQL, MySQL etc. options. When you encounter a problem you don't have a large enough community to ask questions about compared to having issues with typical explicit fetching from client paradigm.

   
   

2. Lack of Standardization

   Building a sync engine that just syncs all the data or doesn't hide any specific column from users is simple. But in the real world you often can't expose all rows or even all columns to the users. This bring us to the problem of partial syncing & managing permissions. Solutions exist for these problem but there are lots of trade offs to be made when making the decision of how to solve them. This lack of standardization means your decisions carry a lot more weight in determining your experience of building with sync engines. This makes it slightly less accessible, specially to newer developers.

Just like all other pieces of technology, there are trade-offs to be made when choosing to build your app on top of a local first stack with a sync engine. However, despite the disadvantages there seems to be overwhelming upsides to building like this, specially if realtime is one of your core features. Right now, I'm in the process of refactoring Osmo so it uses a sync engine and maybe will write about my personal experience of using one in about 6ish months.