Having just hit severe scaling issues with a python service I’m inclined to only write my servers in Go or Rust anymore. It’s only a bit harder and you get something that can grow with you
Convention over configuration and less code is fine, but unfortunately Rails is not a great example of it IMO. The "rails" are not strong enough; it's just too loosey goosey and it doesn't give you much confidence that you're doing it "the right way". The docs don't help much either, partly because of the history of breaking changes over releases. And the Ruby language also doesn't help because of the prolific globals/overrides and implicitness which makes for "magic".
So you're encouraged/forced to write exhausting tests for the same (normally dumb CRUD) code patterns over and over and over again. Effectively testing the framework moreso than your own "business logic", because most of the time there barely is any extra logic to test.
So I'm also surprised it gained the reputation is has.
Although that's really selling it short - it's so much more than that! But in the context of this conversation, it's a good place to look.
Since most websites will never scale past the limitations of these frameworks, the productivity gains usually make this the right bet to make.
At least it’ll make for an interesting post mortem blog post.
How many CVEs have you had reported yet against your custom code for probably the middleware you wrote to get a request with params available to use them (the params) in an SQL query?
Of course if you are good at this and have a lot of experience than even using an LMM I am sure your code is more than fine. But on average I think it is safe to say that any middleware or library code to deal with HTTP requests and make the information available for business logic generated by an LLM has probably a lot of bugs (some subtle some very visible).
For me the power of Rails is that if you do CRUD web apps it is battle tested and has a long history of giving you what you need for fast building business logic for that CRUD app. Is it the knowledge that is put into designing a web framework that works for 90% of the operations you need to write your custom business logic.
upsert_all[1] is available to update a batch of records in a single write that does not invoke model callbacks.
activerecord-import[2] is also very nice gem that provides a great api for working with batches of records.
It can be as simple as extracting your callback logic and a method (def self.batch_update) and running your callback logic after the upsert.
[1] https://api.rubyonrails.org/classes/ActiveRecord/Relation.ht... [2] https://github.com/zdennis/activerecord-import
"It can be as simple as extracting your callback..." Isn't this the kind of repetitive thing a framework should be doing on your behalf?
To be fair, ActiveRecord isn't a fault Rails invented. Apparently it's from one of Martin Fowler's many writings where each model instance manages its own storage. Even Fowler seems to say that the DataMapper approach is better to separate concerns in complex scenarios.
Even outside of batch processing, there will usually be a few queries that absolutely benefit from being rewritten in a lower layer of the ORM or even plain SQL. It's just a fact of life.
Ruby/Rails was a breath of fresh air. Translate: Not a PITA.
Like yeah, I know you can do it. But it was much more effort to do things like writing robust migrations or frontend templates. I’d love to find something in Go or Typescript that made me feel quite as productive as Rails did.
Maybe I am comparing apples and oranges, not sure.