11–20 of 67 posts
to solve N+1 in Ruby Graphql automatically I wrote a thingy that analyzes what fields were requested in a recursive manner and then uses a preloader at the root level to load everything in advance. Solve 80% of N+1 problems automatically.
to solve N+1 in Ruby Graphql automatically I wrote a thingy that analyzes what fields were requested in a recursive manner and then uses a preloader at the root level to load everything in advance. Solve 80% of N+1 problems automatically.
> 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?
> The following query produces the data that we want... we just need to figure out how to write a batch loader that generates the same result. This is where the abstraction breaks down. Should you care what the query ultimately looks like? For anything beyond a toy, you sure should. But how far should you go to ensure the abstraction produces the implementation you want? Why not just skip to the implementation you wa…
> 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 good modular and testable code that avoids the chaos of poor SQL performance etc.
If you're like most organizations and have trash recruiting and training processes for developers, you don't have the luxury of trusting your teams not to fall over with technical debt, and may prefer to use an ORM for immediate short term complexity and also long term technical debt management (since the ORM effectively becomes a framework with consistent patterns that can scale across teams).
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?
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?
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).
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?
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?
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 join is the product of comments*likes for this particular user.
I find the includes stuff easier to reason about as the amount of associations you need loaded in memory becomes more complex.
I'm leaning towards letting the elements of my app that need to be in Rails be in Rails, but moving the GraphQL layer to Hasura, bypassing the ActiveRecord complexity. Has anyone else taken this approach?
It’s a really great engine and I’m glad we took a punt on it. Aside from the expected behaviour, you get some nice bonus stuff like nested updates for free.
We mostly tried it out because we normally use python and we wanted subscriptions. The graphql story in python (especially async) isn’t amazing. When we need more business logic, we’ll build it in python and then you can get Hasura to do delivery to python (to ensure each event is run exactly once).
I’d recommend kicking the tyres to see if it works for you. The team are awesome too, and moving quickly. I have no affiliation but I think it’s going to do really well.