Interview: David Heinemeier Hansson (DHH) on Rails performance and speed
Why Stack Overflow recommends it
Stack Overflow users link it when they need DHH's own reasoning behind Rails design choices such as Turbolinks 5 and querying or caching in views.
Recommended by 1 people across 1 different months, 2016 to 2019.
What it is
A one-hour interview by Nate Berkopec with DHH, the creator of Rails, about Rails performance and whether Rails is still fast enough. It covers why Basecamp avoids heavy single-page JavaScript apps and how it reaches roughly 50 ms response times. It is one of six interviews from The Complete Guide to Rails Performance.
What people said
Recommends inopinatus · 2019-09 · Stack Overflow · on “Rails5.2: avoid N+1 when loading multiples models with resized attachments”
If everything's got an image attachment, then you could turn your thinking inside out and just load the attachments directly, with an includes for the polymorphic record. Attachments are ActiveRecord models too. You might have: @resources = ActiveStorage::Attachment. where(record_type: %w[Album Samplepack Demo Production]). includes(:record). map(&:record) for the main data fetch. It won't be one query, but Rails'll optimise this to be the minimum number of queries (one for all the attachments, and one to load each type in the polymorphic collection). For the variant, the blob query might be unstoppable without a patch to Rails. The alternative to tying yourself in knots over N+1 queries is
Cites Dan · 2016-04 · Stack Overflow · on “Was partial replacement were removed in Turbolinks 5”
Turbolinks jumped from v2 to v5. They were working towards v3 but put a halt on it. In v5 "Turbolinks replaces the current <body> element outright and merges the contents of the <head> element," - so there is no partial replacement. This interview with DHH helps to understand his thinking behind Turbolinks 5 and the jump from v2 - [this video]
Cites slowjack2k · 2016-10 · Stack Overflow · on “SQLI in Show. Is this possible?”
max and @Andrey Deineko, you can't blame sneglefar for doing SQL within the view. I understand your point of view and would give the same recommendation, but only as a recommendation, because DHH says as Rails-Way ( [this video] 7:19) that it is a good thingto execute SQL queries within the view, because it can be cached.