Does Datomic suffer from N+1 query problem?

Datomic Cloud
1

For a nested data schema, we may want to optimize queries to reduce remote-query overheads. As far as I know, for Datomic, queries happens locally.

Let’s say we are implementing a GraphQL API, where the server does not have too much control over what to fetch or how deep do we need to fetch. Do we still need to optimize the queries to produce a nested pull pattern or it doesn’t matter if we let the GraphQL query engine recursively calls a shallow resolver.

2

Hi hden,

It depends. If you deploy your client application as an ion, then queries run in the same process as your application. It you call the client API from your own process, then queries are remote.

Have you looked at Lacinia? Maybe they have already built what you need.

Cheers,
Stu

3

Hi stu,

Thanks for replying. I’m running Lancia from an ion. To be specific, I’m wondering if I should use the nested selection API to optimize the nested pull pattern or should I return the :db/id and let Lancia recursively call the corresponding resolver.

Cheers,
hden

4

@hden I’m also running Lacinia in a Ion and I do exactly this:

  1. use the selection api to see what is needed by resolvers below
  2. read all those entities/attributes in one query and add to the context
  3. lower resolvers look for data already present. if missing, they can still pull themselves

I tried pulling everything at every resolver level but it was slow. Even with Ion locality, it’s best to minimise the number of DB api interactions.