From The Trusted Web To A Foreign Electron
Tags: firebase, electron, offline
Published: 2019-10-14 18:22:51

---
title: From The Trusted Web To A Foreign Electron
published: true
description: Should I go offline-first instead of relying too much on FireBase?
tags: firebase, electron, offline
---

This is a repost from my personal blog [michielnuyts.com](https://www.michielnuyts.com/)

# Offline First

Recently I came across a great [blog](https://jlongster.com/secret-of-good-electron-apps) post from James Long, where he talks about his app Actual and its architecture. This intrigued me because I'm building [spaced-learning.app](https://www.spaced-learning.app) and I rely on FireBase to do all the heavy lifting on the backend and the authentication. This saves me a lot of time to focus on the front-end experience.

However, I've read a lot about the pricing models of serverless options and sometimes they seem too good to be true. Or even a bit scary once you start to really grow. Also, the vendor lock-in is always hanging above my head, what if Google, Amazon or Azure crank up their prices once serverless is popular enough?
This could be a possible scenario in the coming years.

I'll also have less freedom when working with my data because I'm restricted to the exposed firebase API. There are also a lot of stories where pricing got out of hand, anyway I think most of these can be avoided by carefully designing your data model and how you query and mutate your data.

The idea I got from James's Blog was to move the web-app to be a desktop app only using Electron. This way I could still have the flexibility of the web technologies and I could build it as an offline application. I could use SQLite and use the background process that James already figured out in his starter boiler-plate on GitHub.

# I Actually Care About a 'Free Forever' Plan

I'm still not sure if this is the way to go, as just a few days later James [tweeted](https://twitter.com/jlongster/status/1181720749746331649) about kinda regretting his move to Electron because of all the cumbersome aspects of managing and releasing an Electron app. I do think it's a great idea even with the extra complexity and the more pain-in-the-ass release process for the different platforms. Releasing it as a desktop app is a big benefit for my potential users and myself. I do not have to worry about firebase costs anymore. People can just download the app for free and use it forever on their own terms and with totally private data.

I could introduce a premium pricing model where you can sync data in the cloud and provide a mobile companion app. Or some neat features could be behind a pay-wall. All that is still up in the air. My main goal is to provide a really good free experience, free forever.

# Focus

Maybe I should focus on what delivers the most value up front and stick to the Firebase route I'm already on? After some research and trying out the starter boiler-plate from James I know that there will be more complexity if I go this route. I would need to learn more about Electron, the release process and I'd need to write a backend service to let people sync their data. Although I kinda like and encourage the extra complexity, because this project has become a great learning experience where I can tinker away on something truly full-stack, not just in software terms but also in building a product from a to z.

And I actually get pretty excited to try out this background process to handle all queries and mutations in the application. The experience will be near-instant because it's just loading data right from your computer instead of a server somewhere. And working with SQLite also sounds fun. I think I might just do it! You'll know the verdict in my next post.

> "SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine.
> **SQLite is the most used database engine in the world.** **SQLite is built into all mobile phones and most computers** and comes bundled inside countless other applications that people use every day."