Hacker News Reader

Comment by pugio | Hacker News Reader

Really nice to see a deployed modern Rails site. I just recently decided to try Rails 8 out for a side-project of mine (Paranoia RPG virtual table top) and had a generally pleasant experience.

The biggest pain point was the lack of Grade A documentation for the best way to use ActionCable and Turbo – information is spread out between Rails Guides, API docs, and then the Turbo / Stimulus documentation. The actual API docs do a poor job of explaining basic concepts like "streamables", and I kept wondering if I was doing things the "right"/idiomatic way.

Still, as always, ActiveRecord is my biggest draw for Rails, and the new first-class Sqlite integrations are a huge draw for me. I've yet to find an ORM that allows me to be anywhere near as productive.

View on HN

Anyone know what are they using for Analytics?

Edit: Search is nice as well.

>>Really nice to see a deployed modern Rails site.

Yes. And it is also a showcase what I want for 90-95% of the web. Useful as an example next time we have yet another MPA vs SPA or SSR vs CSR argument. It doesn't need to be a complex SPA. Although I must admit the response time isn't perfect even with Cloudflare.

analytics is built with ahoy https://github.com/ankane/ahoy. the project is open source if you need more details https://github.com/adrienpoly/rubyvideo

Hosting is in Europe on Hetzner maybe it explains your response time. Where are you located?

what are the response time you are getting ?

Right now in Hong Kong, getting about 240 - 260ms RTT.

It is probably good enough for 95% of people. I am what I call latency sensitive.

But I think the main culprit is surprisingly view transition isn't as good as I thought. Because the slight lag / jank I feel happens on Chrome. While I dont feel this on Firefox or Safari 17.6 which isn't supported yet.

yes view transition when enabled are applied to all pages and create a blend effect by default which can maybe give this slowness effet?

I will check if we can prevent this default effect and only use page transition when needed

Activerecord is flaw because of n+1 query issue.

n+1 queries can be solved in many different ways – you can easily do`User.all.includes(:character_sheet)` for example, to perform just 2 queries: 1 for users, 1 for their character sheet.

The nice thing about first-class production sqlite support is that even if you do end up with n+1 queries, it's not as big a deal: https://www.sqlite.org/np1queryprob.html

Certainly I wouldn't care about it while prototyping. I can always go back and optimize queries with judicious `.joins()` or `.includes()` if it becomes a bottleneck.

I spent 10 years doing C#, and the last 3 doing Ruby. I never thought of N+1 as that big of an issue. These queries are typically fast (1ms * 100 is still only 100ms…) and multithreaded web servers are non blocking on IO like database calls.

But these sporadic elevated response times kept showing up on endpoints, where they’d be hundreds of milliseconds slower than normal, but by some extension of 100ms. Say, normally 5ms, now taking 105ms, or 505ms, or more.

Then I learned about ruby’s non parallel but concurrent model, where within a process only one thread can execute at a time. In most workloads you’ll hit IO quickly, and the threads will play nicely. But if you have a CPU crunching exercise, it’ll delay every other thread waiting to execute by 100ms before it preempts. Now consider you’re doing 10 1ms queries inter process with a greedy thread, and you’re waiting at minimum 1010ms.

Still love Ruby but the process model gave me a reason to hate N+1s.

Since Rails 7.1 we've had https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FR... which actaully does run queries in parallel.

There's also Rails' russian doll caching, which can actaully results in pages with n+1 queries running quicker than ones with preloaded queries. https://rossta.net/blog/n-1-is-a-rails-feature.html

load_async is still concurrency, but not parallelism. The queries themselves can run parallel, but when materializing AR objects e.g., only one thread can run at a time. A greedy thread in process will still subject you to GVL waits

If that’s a problem for you right now I’d suggest giving JRuby a look as it has no GVL and true multithreading.

Hopefully as Ractors mature that problem will be solved for MRI too.

I also dislike Activerecord. The solution to a lot of this is creating database views and interfacing with that.

Just use ActiveRecord's`find_by_sql` method

The problem is it's a pain to debug through the call chain a.b.c.d.e to figure out where's the cause.

Use `includes` and it's solved, you make it sound like a huge deeply rooted issue, it's not.

Anyone can achieve n+1 issue with whatever tool they use, it's not ActiveRecord specific.

Only with ActiveRecord pattern you need such kind of hacks to prevent, it's why it's flaw.

`includes` is not a hack. Clearly you prefer implicit over explicit when it comes to SQL generation. That's your prerogative, but I strongly disagree. I don't want the ORM trying be clever on me because it is opaque and complex. I want it to use the function arguments to construct a query, and nothing else. Debugging long-running queries is already complex enough without "clever" code trying to abstract it all away from me. Some things should not be abstracted way. It feels nice when your database is small, but it cuts hard when you start to scale.

No u need includes because when u do a.b.c u forgot to includes. It is the api problem for letting u chaining the related objects without including it.

Hibernate has `JOIN FETCH()`, Django has `select_related()`, Entity has `Include()` and so on ...

Very much addressed by tools like bullet, prosopite, strict_loading and others

Reply on news.ycombinator.com