Prisma still sends separates queries to the underlying database

[kasir-barati]

Hi,

I have logged queries generated by Prisma when querying data from PostgreSQL and can see that it is sending two separate queries to the database. So now I do not know if I am interpreting this right or not:

Convert info: GraphQLResolveInfo to select object accepted by prisma client this will give you the best performance because you will just query exactly what you want in RootQuery this mean one resolver so no more N + 1 issue.

— Ref.

As you can see here in my demo app. Steps to reproduce:

1. pnpm i --frorzen-lockfile.
2. nx serve botprobe-nest.
3. nx e2e botprobe-nest-e2e.

And now if you check the logs in your terminal for nx serve botprobe-nest you can see:

[Nest] 2697037  - 12/03/2024, 10:56:07 AM     LOG Parameters: ["5761bc00-42a3-4598-9310-80e80b52f0c0",0]
select
  {
    select: {
      id: true,
      name: true,
      Alert: { select: { id: true, title: true } }
    }
  }
[Nest] 2697037  - 12/03/2024, 10:56:29 AM     LOG Query: SELECT 1
[Nest] 2697037  - 12/03/2024, 10:56:29 AM     LOG Duration: 0ms
[Nest] 2697037  - 12/03/2024, 10:56:29 AM     LOG Parameters: []
[Nest] 2697037  - 12/03/2024, 10:56:29 AM     LOG Query: SELECT "public"."alert_types"."id", "public"."alert_types"."name" FROM "public"."alert_types" WHERE "public"."alert_types"."name"::text LIKE $1 OFFSET $2
[Nest] 2697037  - 12/03/2024, 10:56:29 AM     LOG Duration: 0ms
[Nest] 2697037  - 12/03/2024, 10:56:29 AM     LOG Parameters: ["%leak%",0]
[Nest] 2697037  - 12/03/2024, 10:56:29 AM     LOG Query: SELECT "public"."alerts"."id", "public"."alerts"."title", "public"."alerts"."alert_type_id" FROM "public"."alerts" WHERE "public"."alerts"."alert_type_id" IN ($1) OFFSET $2
[Nest] 2697037  - 12/03/2024, 10:56:29 AM     LOG Duration: 0ms
[Nest] 2697037  - 12/03/2024, 10:56:29 AM     LOG Parameters: ["5761bc00-42a3-4598-9310-80e80b52f0c0",0]

So how is this @paljs/plugin is helping my app to be more performant? Asking since AFAIK the best performance would be when the joins are performed at the database level. Something similar to this new feature of Prisma although as I pointed it out here it is not gonna be something that we can consider as it is now IMO.