Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Efficient GraphQL Queries in Ruby on Rails and Postgres

pganalyze.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Efficient GraphQL Queries in Ruby on Rails and Postgres

#61

Post by imtringued »

e12e wrote: post #13

Somewhat on the side, but: > By using the includes method we've been able to knock our queries down from six to two: The first to find the events, and the second to find the categories for those events. Am I the only one that thinks rails/activerecord is crazy here for (often) preferring two trips to the db over a join on indexed primary keys? Are there really (sane) use-cases where that is better?

Joins don't scale to more than one relation.

Modify the original sample to load two relations: fetch all events with their first 5 categories and all their users. If you use two joins then you get a combinatorial explosion because you are now getting all permutations of the (event, category, user) tuple.

  (event1, category1, user1)
  (event1, category1, user2)
  (event1, category2, user1)
  (event1, category2, user2)

Re: Efficient GraphQL Queries in Ruby on Rails and Postgres

#62

Post by imtringued »

e12e wrote: post #28
blueplanet200 wrote: post #19

Earlier quoted context omitted.

It's more composable with multiple includes. For instance, if you have a simple active record type: class User has_many :comments; has_many :likes; end User.includes(:comments, :likes).find(user_id) Generates 3 queries, but importantly the number of records returned is appropriate. User.joins(:comments, :likes).where(users: { id: user_id }) Generates only a single query, but the number of records returned from this j…

So the problem is active record is no good at joins? (That is, it's hard/impossible via the active record DSL to make the correct nested join?) By the way (you may know this) when staying within active record convention, you should never need to single out the ".id" and ".foreign_model_id" fields: User.joins(:comments, :likes).where(user: some_user) (where some_user is an instance of User). I'm still not quite comfor…

> So the problem is active record is no good at joins?

You encounter this problem whether you use an ORM or not.

Re: Efficient GraphQL Queries in Ruby on Rails and Postgres

#63

Post by imtringued »

X6S1x6Okd1st wrote: post #16
ben_jones wrote: post #15

Earlier quoted context omitted.

To play devil's advocate you could argue many web apps are small internal tools that provide lots of business value but only have small (even single digit) user numbers and thus shouldn't optimize in the slightest for db trips (and instead optimize for maintenance or simplicity).

Just because there are few users doesn't mean inefficiency is fine.

It is because there is no reason why you should waste your time optimizing a page with a heavy query (with thousands of inserts) from 10 seconds to the theoretical 6 seconds that are possible if its only going to be used 20 times and the rest of the time it's simply loading the last cached result?

Also from my experience the performance problems are completely divorced from ORM/not ORM. Usually the reason why you drop the ORM is that you want to take advantage of features that are not modeled by the ORM. Most query optimizations simply involve trying to do everything in as big of a batch as possible. Whether you do batching with or without the ORM isn't really relevant. The reason why people don't batch their queries when they use ORMs is because it's so trivial to not do so but there is no reason why we can't build better ORMs that make batched queries as easy to use as non batched queries which would get us both performance and convenience at the same time.

Re: Efficient GraphQL Queries in Ruby on Rails and Postgres

#64

Post by jmnicolas »

gav wrote: post #29
ben_jones wrote: post #14

Earlier quoted context omitted.

I agree but can't ignore this idiom > If you start without an ORM you end up writing a custom ORM eventually and often that custom ORM is inferior to the third party one you're considering Funny enough this engineering problem becomes an HR one: If your recruiting and training processes can consistently hire devs actually fluent in SQL and web application architecture you can completely avoid the ORM and just write g…

I think this is a really great point, as often the HN answer is "hire better developers". The majority of companies outside the HN bubble are full of very average developers. ORMs work well in that sort of environment as it allows them to be productive, and any performance issues can be tackled by the less-average developers on the team. A while back, I worked with a client who's stack was predominately Java but due…

> The majority of companies outside the HN bubble are full of very average developers.

I think you underestimate the HN bubble : I'm an average dev (I don't even have a Github account !) yet I'm in the HN bubble.

Re: Efficient GraphQL Queries in Ruby on Rails and Postgres

#65

Post by atombender »

ako wrote: post #56
atombender wrote: post #41

Earlier quoted context omitted.

The problem with "just SQL" is that you arguably want to compose queries. A foundational observation that GraphQL makes is that every query is different depending on the client's needs. You can do "SELECT * FROM users JOIN companies ON companies.id = users.employer_id" and call it a day, but now you're already probably overfetching, and the next evolutions of your codebase ends up accruing extra logic to add or remov…

Or you can use OData, which has the same benefits as graphql.

Maybe in principle, but I don't see OData having anywhere near the traction that GraphQL does.

Re: Efficient GraphQL Queries in Ruby on Rails and Postgres

#66

Post by e12e »

blueplanet200 wrote: post #19
e12e wrote: post #13

Somewhat on the side, but: > By using the includes method we've been able to knock our queries down from six to two: The first to find the events, and the second to find the categories for those events. Am I the only one that thinks rails/activerecord is crazy here for (often) preferring two trips to the db over a join on indexed primary keys? Are there really (sane) use-cases where that is better?

It's more composable with multiple includes. For instance, if you have a simple active record type: class User has_many :comments; has_many :likes; end User.includes(:comments, :likes).find(user_id) Generates 3 queries, but importantly the number of records returned is appropriate. User.joins(:comments, :likes).where(users: { id: user_id }) Generates only a single query, but the number of records returned from this j…

Hm, I see now where we're talking past each other - I was thinking more along the lines of "user has orders has order lines has products has prices" (where you might traditionally make a (hierarchy of) database view(s)).

Not "user has orders", and also "user has favorite products".

Re: Efficient GraphQL Queries in Ruby on Rails and Postgres

#67

Post by mdaniel »

sandstrom wrote: post #30

We've looked at GraphQL but ended up going with Graphiti instead. Only a few weeks since we implemented, but happy so far. Feels like it's the best of REST and GraphQL. This page from Graphiti[1] explains the thinking behind it. Don't be discouraged by the loud pink colors ;) [1] https://www.graphiti.dev/guides/why

I guess I shouldn't complain in a thread about GraphQL on Rails, but it's disappointing that Graphiti appears to be only for Rails, and not a general purpose mechanism/specification like GraphQL that it complains about
Post reply on HN