An Introduction to LiteStack for Ruby on Rails

https://blog.appsignal.com/2023/09/27/an-introduction-to-litestack-for-ruby-on-rails.html

by unripe_syntax • 3 years ago

91 37 3 years ago

blog.appsignal.com

The article is actually a great introduction to interfacing a Rails app to Replicate AI!

bradly• 3 years ago

I agree. I didn't learn anything about using LiteStack in a Rails App, but I did enjoy the article and learned of a few new gems and services. The article is the first part of a series and so hopefully in the next part they get into the integration of LiteStack with the app.

julianrubisch• 3 years ago

They will

3by7• 3 years ago

Very compelling architecture for projects that don't require massive horizontal scaling. Those looking for replicas/backups can add Litestream https://litestream.io

kaycey2022• 3 years ago

Is there any restriction on how many rails apps can be run on a 5$ digital ocean droplet?

imacomputertoo• 3 years ago

Yes, memory. 4$ droplets have only 512mb. that's barely enough to run bundle install for one application.

6$ droplets give you 1GB and that's plenty for one app,

ljm2• 3 years ago

You might have some success if you run the build before deploying it (provided you use the same arch as the droplet). It's not going to give you a lot to work with and Puma's default config will take up most of it.

A 1/2GB box could run the bare minimum if you host the database on it as well. For a small scale app or a hobby/toy project that's going to do just fine.

nurettin2• 3 years ago

You can run any number of them if you turn swap on. It will just be very slow.

hartator• 3 years ago

Something feels wrong to use Current.account in models.

lobstrosity4202• 3 years ago

It is in fact how it was designed to be used, you can read the reasoning here: https://dev.37signals.com/globals-callbacks-and-other-sacril...

Toutouxc• 3 years ago

The reasoning being basically "fuck Ruby and consistent OOP practices, this is how we roll". I used to be fine with this, but the more I work with Rails, the more I feel like it's trying to make me a worse programmer. Business logic in controllers, service "objects" (not actually objects at all), the OOP abomination that are models with dozens of different behaviors and agendas inherited via concerns. In Rails you can always pick your poison, but you don't seem to be allowed not to be poisoned.

ljm2• 3 years ago

I see conventions like that as an acknowledgement that Rails often gives up purity in favour of simplicity. It makes this decision quite often, primarily because it works for Basecamp, but also it keeps the mental model simple, especially for juniors learning the ropes.

I've not seen many places that actually use it. Instead there are several other layers of patterns that try to keep things decoupled but introduce a different kind of complexity. And the implementation is different every time (Ruby devs love their custom service/command DSLs).

huntedsnark• 3 years ago

Yeah I think it's one of those features that people generally steer away from. Ironically, if you stick to the "Rails way" of doing things I don't think you would ever encounter it.

pavelevst2• 3 years ago

Agree, models just data layer, not a place for business logic IMO

angryasian3• 3 years ago

It says people are using sqlite for production. How big can you grow your database before it becomes a problem ?

nurettin2• 3 years ago

With binary search and indexes, why should size be a problem?

rco87862• 3 years ago

As big as your disk/SSD.

bradgessler• 3 years ago

281 terabytes

Source: https://www.sqlite.org/limits.html

byroot• 3 years ago

The limiting factor isn't the size of the dataset, but the rate of writes.

angryasian3• 3 years ago

thats interesting I thought it would be faster than your avg database. I'll have to dig into it.

melx• 3 years ago

Something else will be a problem...before size of sqlite is a problem.

angryasian3• 3 years ago

thanks, yeah I haven't dug deep enought to understand what those would be yet.

stmblast• 3 years ago

This is neat! I like.

It reminds me somewhat of Turso.

rco87862• 3 years ago

Oh dang I love this.

I also wish someone would take something like this and go full Phoenix with it.

revscat3• 3 years ago

Phoenix?

lemper• 3 years ago

Ruby off Rails inspired framework for Elixir.

lastairnomad• 3 years ago

Phoenix already doesn't need Redis for asynchronous jobs and caching. I'm using Phoenix on SQLite on a project right now, and it's been working pretty flawlessly. It's as easy as `mix phx.new MyProject --database sqlite3`.

enstyled• 3 years ago

Here's more on the subject from Fly.io https://fly.io/ruby-dispatch/sqlite-and-rails-in-production/

pavelevst2• 3 years ago

VM with 1GB ram and some swap file can easily run rail app, Postgres and redis. With that you don’t have to limit yourself to not able to scale later. I never used sqlite, can it be used by multiple process simultaneously? Eg rails server and rails console

fractaledmind2• 3 years ago

When you open your database connection in WAL journal mode, you can have multiple concurrent readers. This is the new default for all Rails applications. WAL mode doesn’t allow concurrent writers, but you are often talking about milliseconds to wait for the busy connection to resolve, and SQLite retries for you invisibly.

mycroftholmess• 3 years ago

What would be the deployment strategy here?

Would it have to be manual deployments? Since the infrastructure for other approaches usually assumes that there isn’t any critical data on a single instance.

The .sqlite file would have to be persisted somehow?

fractaledmind2• 3 years ago

Yes, the .sqlite file needs to be persisted across deployments. It is fairly common for the /storage directory to be persisted across deployments. The Kamal deployment tool will use this directory. The Hatchbox.io service likewise uses a persisted /storage directory.

This doesn’t mean that you have to have manual deployments tho. You simply need a file system and some persisted storage, which you should already have as most deployment setups don’t want to nuke and pave every static asset on every deployment.

An Introduction to LiteStack for Ruby on Rails

Related Stories