Message originally sent by slack user U783MOJYF8Z
We probably won’t commit a lot of resources to this in the short term, but I’ll put it on my list of things to think about 
Message originally sent by slack user U783MOJYF8Z
Will definitely report back once I know more.
Message originally sent by slack user U783MOJYF8Z
<@U783UION177> I think I remember now why we haven’t looked into using generalized batch loaders for this more deeply.
IIRC, the thing is that our current GraphQL implementation with batch loaders that are tightly integrated with both GraphQL and ActiveRecord is is very efficient, and we weren’t ready to take on the degraded performance that would probably result from such an approach.
Why would performance degrade?
• our current implementation loads only fields that were requested through graphQL. That means, if a computed field has additional database dependencies, we only load those if that field was requested. I’m not sure how we would map that to the generalized batch loader approach you described.
• our current implementation knows exactly when to fulfill the batch loader promises, which means we can keep the number of DB queries very low. We first resolve the query, and then fulfill a tree of promises in the right order. That means that if there are multiple branches of the query that need data from the same table, we will (most of the time) only query that table once.
Which is why we’ve invested quite a bit into a query layer library that analyzes the whole query upfront, and then generates optimized DB queries from that.
I do think though that the tradeoff for generalized batch loaders may be worth it if it significantly simplifies the implementation (which it looks like).
Message originally sent by slack user U783UION177
Yeah, I get that <@U783MOJYF8Z>. As we roll this out I’ll need to keep an eye on performance for sure. My current plan is to put the code responsible for real estate (listing) management, which could be analogous to shop or product management in your case, and code responsible for consumer search, in separate contexts. One benefit to this approach is that listing (or shop/product data) can be denormalized in the Search context in a way optimized for search. The GQL queries used for data management can be a little slower, and those GQL queries that need to be fast for consumers might not have any joins at all.
This is an oversimplification of what we’re doing, but hopefully you get the idea.
Message originally sent by slack user U783MOJYF8Z
That makes sense. One of my biggest gripes with GraphQL though is that it moves a lot of complexity into the consumer and gives them so much control over what queries exist. So the backend has to be optimized to executed any random query efficiently, which doesn’t lend itself well to abstractions
Message originally sent by slack user U783UION177
Yeah I’m definitely not yet sold on GQL being better than REST when your clients are under your control and their use cases are well understood by the team implementing the backend api. Having said that, we have decided to go all in on GQL.
I still thinking it will be beneficial to use our knowledge of our use cases in our GQL schema. So this mean the same data will be exposed by multiple GQL nodes. This allows us to segment queries as mentioned above with different performance characteristics (e.g. these are our management queries and these are our search queries). This also allows us to hide some of that client complexity when it’s well known and/or shared across multiple clients.
This might be a bad idea, but applications exist to fulfill use cases, so it makes sense to me to use this knowledge in the schema.
Message originally sent by slack user U783UION177
I haven’t come across blog posts on these ideas. If you have, either for or against, please send them my way.
Message originally sent by slack user U783MOJYF8Z
I have not, but would also be very interested