Hacker News Reader

Comment by cgrealy | Hacker News Reader

Offline mode adds significant complexity to the service, since you are essentially replicating your entire server side stack (logic, storage, etc) on the client.

Offline mode adds a cost to every new feature, even if it's just deciding if you are going to support said feature offline.

If you're dealing with sensitive data, it also means you need a way to secure that data on the client device.

I'm not saying apps shouldn't have an offline mode, but software engineering resource isn't free and most businesses would need to justify the cost of offline (even if it's just an opportunity cost).

View on HN

Offline-first forces you to reconsider your design / architecture.

It does not force you to replicate your functionality.

What forces you to replicate your stack is poorly designed architecture.

He said "software engineering resource isn't free" so online-only may require simpler and cheaper solution. For business point of view, that architecture is considerably great, not poor.

As someone who have done offline first apps, my default will be to make it all online unless it seriously impact the user experience. The complexity trade off is not worth it in most contexts. At the end of the day, it really depends on what your apps do.

Yeah offline first is absolutely an amazing user experience, especially once you start really taking advantage of preloading/eager loading. But it is far from free. The backend services and data modeling will be a large factor in how much you can do on the frontend. Conflict resolution is potentially an unsolvable problem. I dont think you need to replicate all backend logic on the frontend, but you likely do need some of it, which as you said, adds more cost to features (and usually has potential for bugs if you aren't in the same stack on frontend/backend).

The frameworks for offline are few to nonexistent, and of those that do exist they also seem very new and not battle tested in production. It’s a hard problem because there’s more states than online and offline. There’s also “a connection is detected, but I cannot connect to anything” state

One I’ve used before is BreezeJS[0], and it’s been around for over 8 years, maybe longer. It’s a data framework which takes care of managing dynamic object graphs, providing ways to query, save, and track local changes.

[0] http://breeze.github.io/doc-js/

> Offline mode adds significant complexity to the service, since you are essentially replicating your entire server side stack (logic, storage, etc) on the client.

Not necessarily true if you can run the same code on the client as you do on the server.

That’s doable, but it’s not without its own issues.

Plus, you frequently don’t want to architect your client code the same as your server code (you’re not going to run a bunch of micro services on the client side for example)

Not necessarily. Most database libraries support SQLite as an option, and if you must use PostgreSQL or MySQL, then having a container app solves those purposes nicely. Personally I'd like to see more applications move to file based storage, which scales more easily on distributed storage systems.

Again, it really depends on the application.

Maintaining multiple sources of truth is hard, especially if multiple people are working on the same data.

File systems can be used similar to a database with user locking as well. I'm not suggesting it doesn't come with new challenges but the apps I've used that write and read from files are pretty phenomenal and much easier to scale.

File systems are not a replacement for a database.

Files store information. Databases store information. Structuring data into folders and files to store data is not much different than structuring data in a file to store data.

Data structure is only a small part of what a database gets you.

Have you actually done this in production?

What was the user load like? Performance / latency?

In that case, I better use the website and avoid the app altogether.

App and website are really interchangeable here. Both are just clients.

You can absolutely implement offline in a web application (Google drive does this). Obviously, you need to be online to get the app in the first place, but once it’s cached, you should be good to go.

Again, it’s a cost-benefit analysis for the business.

The most frequent reason for offline mode I heard is "using app while being off grid" which is quite ironic to me since it's when people suppose to do something else. This excludes offline-only apps like calculator.

Just because you’re off the grid doesn’t mean you’re not working.

You might be at a remote site, or on a plane with no Wi-Fi.

But, yeah, if those are common use cases for your app, you should absolutely be designing for offline.

I tried coding on a plane, it's super unproductive. Off-grid, to me, means reading book, playing sport, enjoying nature etc. No internet, no work. The time in your entire life without the internet connection is so short really.

I am the same, but there are people who don't have that choice.

Your job may literally involve entering data at a remote site with sketchy-to-no internet (mines, farms, geological surveys, etc).

Reply on news.ycombinator.com