Firebase+Vue or Phoenix LiveView?

Facing a fundamental decision while looking to build a web app for small farms — pretty much a typical SAAS database app but with a non-traditional, more interactive UI. The problem is that a lot of these farms have terrible Internet connectivity (just check out this report!). Eventually, the app will go international where connectivity is possibly even worse.

I really love Elixir, Phoenix and especially LiveView. I’ve built some test apps, and tried them both using bad cellphone connections and with browser latency/speed limits. The efficiency of LiveView on the wire goes a long way but if the signal drops, the user is really stuck.

Looking for alternatives, the most viable option seems writing a Vue app that interacts with Firebase. Firestore has good data caching and even stores writes while offline locally (reflecting them back to your app) while re-syncing as soon as the Internet connection is back. To build an occasionally-offline app, it seems like this would be ideal, but I feel very suspicious about that beyond a simplistic CRUD example. It’s the opposite of the elegance of LiveView.

Phoenix (either LiveView or old-fashioned HTML with minimal JS) provides a single source of truth with everything always in sync, plus so many other advantages that make the app more robust and easier to develop. No wonder the forums here exude developer satisfaction.

Another possible solution may consist of both:

  1. To deal with poor connection, minimize LiveView trips, so don’t use it on every keystroke, or in simple interactions like clicking a different tab or a menu.
  2. To deal with no connection, embed an almost entirely separate “offline” version of the app that looks the same but is merely a read-only version snapshot with the most recent data (which would have to be refreshed periodically).

Both would several reduce the elegance and speed of LiveView, but maybe there could be generalized way to implement this so it doesn’t need lots of extra code for every feature.

Am I overthinking this? Or wishing for something impossible? Or is there a way to make this work?

Thank you!


You may consider

Ive recommended this post elsewhere on the forum, this is a super &very interesting approach:

1 Like

Super interesting, thanks! My first thought was that this would have lots of potential in combination with Elixir Desktop. But I would be worried about updates. If they already have bandwidth problems, they’re unlikely to install regular updates and dealing with outdated versions of the app floating around that have to continue syncing seems like a nightmare. The more I explore, the better straightforward LiveView looks (incredibly efficient bandwidth usage), with a maybe a “low network” mode that avoids certain calls (like per-keystroke validation), and a very small offline app version that provides essential tasks.

It’s an excellent post and a fascinating solution, thank you! Thinking through this, I would like to avoid adding to much complexity to the entire app by putting offline code everywhere, but I think it has lots of useful ideas and techniques to consider a separate offline portion of the app that could be activated and allow for essential functionality. For farms that are truly remove with zero connectivity, this might mean they go into town with their laptop to use the app properly, and then come back and get what they need to look at essential data, print documents and labels needed for planting or harvest, etc.

The more I look into different solutions, the more I appreciate the efficiency and elegance of LiveView!

A thought, while looking into this: just like a “Reduce Motion” feature in accessibility that will skip animations, I am thinking of a “Reduce Network Use” mode for my app that would minimize both bandwidth (choosing lower res WebP images, for example) and server roundtrips (like keystroke validation) but still keep the app fully functions. This could eventually make its way into a separate library (or even as part of LIveView) to address perf concerns on poor connections.

1 Like

I do think LV alone offers much of what you need - in the sense of keep as much state as possible on the server.

I would also consider Live view native for your use case.

The most excellent team gave a recent presentation here:

You can keep local state with AppStorage, SwiftData etc… but still benefit from all the LV goodness. (I’m finding my feet with it incorporating into a current swiftuii project aware that no doubt there’s much still that will be subject to change)

(and really - Swiftui has made iOS dev trivial imo )

Thanks Pal — I agree about LiveView alone offering much of what I need, and in some ways it offers a much better solution for poor connectivity. If people have high latency and terrible bandwidth, they’re not going to download (or, importantly, update!) a big, heavy client-side app, so being able to serve pages quickly and then using minimal network (which is exactly what LV) is hugely beneficial.

Yes, I’ve looked at LiveView native with great interest. My (recent) background is in iOS development so I may even be able to find some opportunities to contribute (especially around navigation).

There is still so much to learn but the deeper I get into this, the more exciting and affirming everything feels!


It’d be pretty nifty if that mode’s automagically toggled on/off based on a sliding window tracking connection/signal strength!

1 Like