Where Your App Actually Runs

Created on July 22, 2025

#SaaS #Architecture #Web Development #Product Strategy #Case Study

Yes — for a web collaborative app, the browser can keep a local copy of data and sync changes with the server and other users.

A modern app usually has three parts:

  • Frontend
  • Backend
  • Database

The key question is where each one lives.

1. Remote Backend, Remote Database

The backend and database live on the server.

The frontend can reach the user in two ways.

Browser

The frontend is delivered over the web.

Browser → Frontend files → Backend → Database

The browser may cache those frontend files, so they do not need to be downloaded from scratch every time.

Updates are still controlled from the web.

Installed App

The frontend is bundled with the application and already exists on the device after installation.

Installed frontend → Backend → Database

The UI is local, but the app may still depend on the network for most data and actions.

Note: The line between web and installed apps is blurry. A web frontend can be installed as a PWA, while native apps can also run a web frontend inside a WebView.

Why use this model?

  • Simple architecture
  • Centralized data
  • Easy synchronization
  • Good when users are usually online

The trade-off is that many interactions still depend on the network.

2. Frontend + Local Database

For a faster experience, keep both the frontend and core data on the device.

Frontend → Local database

Reads and writes happen locally.

The server is mainly used for synchronization:

Local database ↔ Server ↔ Other devices

This also works for web apps. The browser can store data locally using technologies such as IndexedDB, then sync changes with the server.

What about collaborative web apps?

The same model can still work.

Each user keeps a local copy:

User A local data ↔ Server ↔ User B local data

Changes appear locally immediately, then sync with the server and other collaborators.

So collaboration does not require every action to wait for the server.

The difficult part is handling cases where multiple users change the same data at the same time.

Why it feels better

  • Faster reads and writes
  • Immediate UI updates
  • Works better on weak connections
  • Can continue working offline

The trade-off

You now have to manage synchronization:

  • Multiple devices
  • Multiple users
  • Offline changes
  • Conflicts
  • Failed syncs
  • Stale data

The Main Difference

In the first model, the server is the center of the application.

In the second, the device has its own working copy of the data, while the server keeps everyone in sync.

And one important distinction:

Caching frontend files is not the same as keeping application data local.

A browser app can have its frontend fully cached and still depend on the server for every data request.

Local data is what makes the app feel immediate.

← Back to Writeups