litestack VS firestarter

The benchmarks for LiteCache are impressive, with a small caveat. While LiteCache outperforms a local Redis installation for every read operation, it seems like there's still room for improvement, especially for large write payloads.

Luckily, the official LiteStack benchmarks include measurements for LiteCable against Redis, which I am going to quote here.

Let's quickly look into how LiteJob uses SQLite to implement a job queueing system. In essence, the class Litequeue interfaces with the SQLite queue table. This table's columns, like id, name, fire_at, value, and created_at, store and manage job details.

Next, we install LiteStack using the shipped generator:

Related: I wrote a piece last week on deploying Rails apps to production on Fly.io at https://fly.io/ruby-dispatch/sqlite-and-rails-in-production/

The work that’s made this possible is:

1. Litestack - https://github.com/oldmoe/litestack

2. Fly.io’s work on the dockerfile-rails generator detecting Sqlite and Litestack in a Rails project, then setting up sane defaults for where that data is stored and persisted in production. This is all done behind the scenes with no intervention required from the person deploying.

3. Servers are overall faster and more powerful

I hope more Rails hosts make it easier and safer to deploy Sqlite to production. It will lower costs and reduce complexity for folks deploying apps.

Didn't know that one! The litestack.gemspec shows it's a wrapper around the sqlite3 gem. So, not really comparable...

I’m working on this for Rails apps at https://github.com/oldmoe/litestack/pull/12

The idea is that people with small-to-medium size Rails Turbo apps should be able to deploy them without needing Redis or Postgres.

I’ve gotten as far as deploying this stack _without_ LiteFS and it works great. The only downside is the application queues requests on deploy, but for some smaller apps it’s acceptable to have the client wait for a few seconds while the app restarts.

When I get that PR merged I’ll write about how it works on Fly and publish it to https://fly.io/ruby-dispatch/.

Rails is the way to go. The productivity of the Ruby language is insane. It's battle tested for decades and you can easily scale your prototype.

If you want a simple app served on a single host you can try LiteStack [0] so you don't need a Redis/Postgres/Sidekiq instance, just SQLite.

Laravel is also good if you like PHP language.

[0] https://github.com/oldmoe/litestack

Building a SaaS and web app starter kit https://github.com/mcapodici/firestarter using NextJS, Firebase and Tailwind

Working on a ChatGPT tutorial now for it:

I agree. I accidentally ended up using the very basic todolist in my starter kit https://github.com/mcapodici/firestarter for all my todos! And noticed the ui and ux issues as a result.

My open source project is mostly aimed at this. Happy to help out early adopters (find me on twitter @mcapodici)

https://github.com/mcapodici/firestarter

1. Check

2. Check: I started using github spaces developing this

3. Check

4. Uses Firebase, trading off open sourceness for convenience

Firestarter https://github.com/mcapodici/firestarter, is perhaps a more humble project than most.

It is an attempt to build what is (in my opinion!) a great stack for quickly iterating on a web app idea. Probably about a month off from first release, which will be a simple TODO app you can sign up for, with full instructions on getting it set up and deployed that would be about an hour's work. From that point you have a semi-professional setup with devops and CI taken care of so you can move faster on your idea or startup.

Uses Firebase/NextJs/Vercel/React/Tailwind/Github Actions/Jest/Testing Library

This is something I have been considering as I work on firestarter [0] which is a going to be an open source starting point for building a SaaS.

I decided tests are a good thing to have, and especially when already set up and you can easily add more by following the pattern.

I prefer unit tests that are narrow in scope and avoid IO interactions (for example databases)

Of course anyone using my framework can ignore the tests if they desire. But my gut feeling is tests save you time in the short run as well as long run.

[0] https://github.com/mcapodici/firestarter