Clojurians Log v2
pathom
Hi. Any suggestions for using batch resolver for the N+1 problem when using a database. The way I see it, in order to "reuse" resolvers when querying a remote db (say, user_group->user), if I have a user_group resolver and a user resolver, I will get hit by the N+1 problem when returning only {:user/id 2222} in the user_group resolver. I guess I can create a query that performs the join inside the user_group resolver but that causes duplication and looses the pathom magic.
@reshef.mann pathom (alone) do not solve n+1 problem
There is projects like #walkable that try to help about it.
There is cool ideas here too (not directly related to pathom, but I believe that this ideas can help with a solution):
https://blog.jooq.org/2019/11/13/stop-mapping-stuff-in-your-middleware-use-sqls-xml-or-json-operators-instead/
I think that is important to remember that in modern db's like #datomic , n+1 isn't a problem at all, once every access is in-memory.
@souenzzo Thanks for the helpful info! It was more out of curiosity. For the project I'm talking about I'm using Crux so the same traits of datomic apply as well.
In my experience, using datomic, even on 3-level joins (list some users, for each user get all addresses, for each address get something else), i have no performance problem (once everything is on db).
@reshef.mann A practical approach, that can be used to solve not only n+1, but any performance problem in #pathom:
- Develop your app, write small/simple/naive resolvers to connect/deliver your app
- Deploy your product, let the client's do requests
- Collect statistics about which queries and which resolvers are slow//called too much (pathom trace will help)
- Create specialized batch resolvers for these situations
- Pathom will smartily choose the faster resolver for the query.