[HN Gopher] An Introduction to LiteStack for Ruby on Rails
       ___________________________________________________________________
        
       An Introduction to LiteStack for Ruby on Rails
        
       Author : unripe_syntax
       Score  : 81 points
       Date   : 2023-09-27 10:21 UTC (12 hours ago)
        
 (HTM) web link (blog.appsignal.com)
 (TXT) w3m dump (blog.appsignal.com)
        
       | 3by7 wrote:
       | Very compelling architecture for projects that don't require
       | massive horizontal scaling. Those looking for replicas/backups
       | can add Litestream https://litestream.io
        
       | angryasian wrote:
       | It says people are using sqlite for production. How big can you
       | grow your database before it becomes a problem ?
        
         | nurettin wrote:
         | With binary search and indexes, why should size be a problem?
        
         | melx wrote:
         | Something else will be a problem...before size of sqlite is a
         | problem.
        
         | rco8786 wrote:
         | As big as your disk/SSD.
        
         | byroot wrote:
         | The limiting factor isn't the size of the dataset, but the rate
         | of writes.
        
         | bradgessler wrote:
         | 281 terabytes
         | 
         | Source: https://www.sqlite.org/limits.html
        
       | kaycey2022 wrote:
       | Is there any restriction on how many rails apps can be run on a
       | 5$ digital ocean droplet?
        
         | nurettin wrote:
         | You can run any number of them if you turn swap on. It will
         | just be very slow.
        
         | imacomputertoo wrote:
         | 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,
        
           | ljm wrote:
           | 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.
        
         | [deleted]
        
       | hartator wrote:
       | Something feels wrong to use Current.account in models.
        
         | ljm wrote:
         | 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).
        
         | lobstrosity420 wrote:
         | 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 wrote:
           | 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.
        
             | revscat wrote:
             | You may want look into dry-transaction and railway oriented
             | programming.
        
               | arrowsmith wrote:
               | Or you could give it up and move to Phoenix; I've never
               | looked back.
        
             | lobstrosity420 wrote:
             | > Maximalist positions are a thing in our industry. Take a
             | technique, outline its drawbacks, extrapolate you can't use
             | it under any circumstance, and ban it forever. We are lucky
             | that Rails embraces exactly the opposite mindset as one of
             | its pillars.
        
         | huntedsnark wrote:
         | 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.
        
       | rco8786 wrote:
       | Oh dang I love this.
       | 
       | I also wish someone would take something like this and go full
       | Phoenix with it.
        
         | revscat wrote:
         | Phoenix?
        
           | lemper wrote:
           | Ruby off Rails inspired framework for Elixir.
        
       | obiefernandez wrote:
       | The article is actually a great introduction to interfacing a
       | Rails app to Replicate AI!
        
         | bradly wrote:
         | 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.
        
       | enstyled wrote:
       | Here's more on the subject from Fly.io https://fly.io/ruby-
       | dispatch/sqlite-and-rails-in-production/
        
       | stmblast wrote:
       | This is neat! I like.
       | 
       | It reminds me somewhat of Turso.
        
       ___________________________________________________________________
       (page generated 2023-09-27 23:02 UTC)