This is a repost from my personal blog michielnuyts.com
Offline First
Recently I came across a great blog post from James Long, where he talks about his app Actual and its architecture. This intrigued me because I'm building 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 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."
Top comments (0)