Live data from Hacker News

An Introduction to LiteStack for Ruby on Rails

blog.appsignal.com

21–30 of 39 posts

Re: An Introduction to LiteStack for Ruby on Rails

#25

Earlier quoted context omitted.

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...

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 ca…

You may want look into dry-transaction and railway oriented programming.

Re: An Introduction to LiteStack for Ruby on Rails

#27
post #25

Earlier quoted context omitted.

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 ca…

You may want look into dry-transaction and railway oriented programming.

Or you could give it up and move to Phoenix; I've never looked back.

Re: An Introduction to LiteStack for Ruby on Rails

#29
post #26

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

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

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

Re: An Introduction to LiteStack for Ruby on Rails

#30
post #23

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

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

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