Worried about Prisma Next

[DarkKingpro10]

Question

Concern about loss of composable query objects in Prisma Next

First of all, I really like the direction Prisma Next is taking. The new query API looks significantly more readable and avoids deeply nested structures.

However, I have a concern regarding a pattern that is heavily used in real-world applications: composable query objects for business logic.

Current pattern (Prisma 7)

In many production systems, we build queries dynamically using plain objects:

const filters: Prisma.ProductoWhereInput = {
  ...baseFilters,
  ...(search ? { nombre: { contains: search } } : {}),
};

We also encapsulate domain logic in reusable functions:

export function buildListaPrecioDetalleFilter(...) {
  return {
    listaPrecio: {
      ...base,
      canalComercial: { isActive: true, codigo: canalCodigo },
    },
  };
}

This allows us to:

• Compose queries dynamically
• Reuse business logic across services
• Keep queries declarative and serializable
• Pass filters across layers (services, fetchers, etc.)

---

Concern with Prisma Next API

With the new chain-based API:

db.orders
  .where(...)
  .include(...)

It seems harder (or impossible?) to:

• Compose filters using object spread (...)
• Build queries incrementally outside the query execution
• Reuse query fragments as plain data structures

This pattern is critical in systems where business logic determines query structure dynamically.

---

Questions

1. Is there an equivalent pattern in Prisma Next to compose queries as reusable data (similar to WhereInput)?
2. Are "collections" intended to replace this use case?
3. How would you recommend handling dynamic filters built across multiple layers (e.g., service + domain + user input)?
4. Is there any plan to support a hybrid approach (object-based + chain-based)?

---

Suggestion

If this pattern is not directly supported, it would be great to have:

• A way to define reusable query fragments
• Or a builder that can be passed around before execution
• Or documentation on how to migrate this pattern using collections/extensions

---

Why this matters

This is not just a stylistic preference — it directly impacts:

• Separation of concerns
• Reusability of business logic
• Maintainability in large codebases

---

Thanks again for building Prisma Next in the open. This kind of feedback loop is really valuable.

How to reproduce (optional)

No response

Expected behavior (optional)

No response

Information about Prisma Schema, Client Queries and Environment (optional)

No response

[soosho]

The piped API doesn't stop you from composing conditions dynamically — you just compose the arguments instead of the whole object.

With Prisma Next's pipe syntax, you can still build reusable filter factories:

// Build filter conditions the same way, just pass them to the pipe
const filters = {
  ...baseFilters,
  ...(search ? { nombre: { contains: search } } : {}),
};

const result = await db.producto
  .where(filters)
  .orderBy({ precio: 'asc' })
  .select({ id: true, nombre: true })
  .exec();

Your buildListaPrecioDetalleFilter() functions still work — they just return the filter object instead of embedding it inside a where: key:

export function buildListaPrecioDetalleFilter(opts: FilterOpts) {
  return {
    listaPrecio: {
      ...base,
      canalComercial: { isActive: true, codigo: opts.canalCodigo },
    },
  };
}

// Usage hasn't changed meaningfully
const result = await db.producto
  .where(buildListaPrecioDetalleFilter({ canalCodigo }))
  .exec();

The main difference is that you're piping methods instead of nesting keys. The composition patterns — spread, conditional spreads, helper functions returning filter objects — all carry over directly because the where() clause still accepts the same Prisma.ProductoWhereInput type under the hood.

For cases where you need to dynamically add/remove entire clauses (sort, pagination, etc.), the pipe actually makes it cleaner:

let query = db.producto.where(filters);

if (sortField) query = query.orderBy({ [sortField]: sortDir });
if (page) query = query.skip((page - 1) * limit).take(limit);

const result = await query.exec();

That's harder to do with the nested object syntax.

[chrisjcthomas]

Your concern about composition in a method-chained API is highly valid. Object-based queries in Prisma 7 made dynamic filters, conditional spreads, and fragment sharing trivial.

However, chain-based query APIs are declarative and lazy under the hood, meaning you can still compose queries dynamically using the following patterns:

1. Incremental Query Building

Instead of immediately awaiting a query, you can build the query builder instance incrementally by conditionally chaining methods:

async function getFilteredProducts(search?: string, baseFilters?: Prisma.ProductoWhereInput) {
  // Start the base query builder
  let query = db.products.where(baseFilters || {});

  // Conditionally add filters
  if (search) {
    query = query.where({ nombre: { contains: search } });
  }

  // Chain includes and finally execute the query
  const results = await query.include({ category: true });
  return results;
}

2. Functional Composition (Reusable Fragments)

You can write helper functions that accept a query builder and return a modified builder. This encapsulates business logic and keeps it reusable across layers:

// Encapsulated domain logic
export function withActivePriceList(query: any, canalCodigo: string) {
  return query.where({
    listaPrecio: {
      canalComercial: { isActive: true, codigo: canalCodigo },
    },
  });
}

// Usage:
const query = db.products.all();
const filteredQuery = withActivePriceList(query, 'retail');
const results = await filteredQuery.include({ details: true });

3. Utilizing Client Extensions

Prisma Client Extensions allow you to attach custom methods directly to your models, acting as a native way to share query composition:

const prisma = new PrismaClient().$extends({
  model: {
    product: {
      async findActiveByChannel(canalCodigo: string) {
        return prisma.product.findMany({
          where: {
            listaPrecio: {
              canalComercial: { isActive: true, codigo: canalCodigo }
            }
          }
        });
      }
    }
  }
});

[Saif0933]

I think this is a valid concern, especially for larger applications where query construction is part of the business layer rather than something written inline at the point of execution.

One thing I would separate is query composition from query execution.

In Prisma 7, WhereInput objects naturally acted as a composable intermediate representation:

const filters = {
...baseFilters,
...(search && {
nombre: {
contains: search,
},
}),
};

Because these are plain objects, they are easy to:

Merge with spread operators
Pass between services
Test independently
Serialize if needed
Build incrementally across layers

The concern with a chain-based API is that the query becomes an executable construct much earlier in the process.

For example:

db.products
.where(...)
.where(...)
.include(...)

is very readable, but it's less obvious how to build that across multiple modules without coupling business rules to the query implementation.

A possible approach

One pattern that might preserve separation of concerns is to keep domain logic returning plain filter definitions and only convert them into a query at the final execution layer.

Something like:

function activeProductsFilter() {
return {
isActive: true,
};
}

function searchFilter(search: string) {
return search
? {
name: {
contains: search,
},
}
: {};
}

Then:

const filter = {
...activeProductsFilter(),
...searchFilter(search),
};

db.products.where(filter);

If Prisma Next still accepts object-based filters inside the chain API, this would preserve most of the existing architecture while benefiting from the new syntax.

My biggest concern

The challenge is not readability of individual queries.

The challenge is maintaining:

Reusable domain filters
Shared business rules
Multi-layer query construction
Testable query logic

These are extremely common requirements in enterprise applications.

What would be ideal

A hybrid model would probably offer the best developer experience:

const filter = buildProductFilter(...);

db.products
.where(filter)
.include(includeConfig);

This would allow:

Chain-based readability
Object-based composition
Gradual migration from Prisma 7
Better separation between domain logic and persistence logic

So my question would be: Is the intention that filter objects remain the primary composable unit and the chain API simply becomes a more ergonomic execution layer, or is Prisma Next moving toward query builders as the main composition mechanism?

The answer to that will likely determine how easy it is for large codebases to migrate existing business-logic-heavy query patterns.

[logusivam]

This is a well-articulated, important concern, and the good news is that "collections" — which you specifically asked about — are exactly the answer to most of what you're describing, though they work differently from object-spread composition rather than replicating it directly. Let me walk through what's actually there based on what Prisma has published so far.

---

Answering your numbered questions directly

1. Is there an equivalent to composing WhereInput as plain data?

Not as plain object spreading, based on what's been shown publicly so far. Prisma Next's SQL query builder uses a fluent chain syntax — db.sql.selectFrom(...).leftJoin(...).select(...).orderBy(...) — and the ORM-level query API follows the same chain-based pattern rather than nested/spreadable objects. The deeply-nested WhereInput-style object you're composing with ...baseFilters doesn't have a published direct equivalent as inert, serializable data in Prisma Next's current design.

2. Are "collections" intended to replace this use case?

Yes — this is the closest mechanism to what you're asking for, but it composes through method definition and chaining, not object spreading. Prisma Next introduces "model collections," where you extend a Collection<Contract, "ModelName"> class and define your own reusable methods that wrap query logic — for example a forUser(userId) method that internally calls this.where({ userId }), and a newestFirst() method that calls this.orderBy(...). These are then chained together: db.posts.forUser(userId).newestFirst().take(20).all().

This gives you reuse of business logic across services (your stated goal), but the unit of reuse is a named method on a class, not a portable plain object you can spread or merge at runtime.

3. How to handle dynamic filters built across multiple layers?

Based on what's published, the equivalent pattern in Prisma Next would be composing chained method calls rather than merging objects — something like calling multiple collection methods conditionally:

let query = db.products.where({ ...baseFilters });
if (search) {
  query = query.where({ nombre: { contains: search } });
}

This works if .where() calls are chainable and additive (each call narrows further) rather than replacing the previous filter — which appears to be the model based on the chain-based design shown, but Prisma hasn't published explicit documentation yet confirming exactly how multiple .where() calls combine (AND vs. replace). That ambiguity is worth asking about directly, since it's central to your use case.

4. Is there a planned hybrid approach (object-based + chain-based)?

Nothing in the published material suggests a hybrid is planned. The architecture as shown is chain-first for both the ORM API and the new SQL builder. Prisma describes the redesign's explicit goal as moving away from the "cascade of closing braces" problem of deeply nested objects, which was a deliberate motivation for the chain-based rewrite — so a return to spreadable nested objects as the primary interface would cut against that stated design goal. A hybrid isn't ruled out, but there's no indication of one being planned as of the current public material.

---

The genuinely good news: collections solve more of this than it first appears

Re-reading your two example patterns through the collections lens:

Your buildListaPrecioDetalleFilter(...) function becomes a named collection method instead of a returned object:

class ListaPrecioCollection extends Collection<Contract, "ListaPrecio"> {
  forCanalComercial(canalCodigo: string, base: BaseFilters) {
    return this.where({
      ...base,
      canalComercial: { isActive: true, codigo: canalCodigo },
    });
  }
}

This preserves reusability across services and keeps the domain logic in one place — arguably more discoverable than a loose exported function, since it's attached directly to the model's query surface and gets autocomplete. What it does not preserve is treating the filter as inert serializable data you can log, diff, send over the wire, or merge with ...spread outside of a query context. If any of your current usage relies on that — e.g., serializing a filter object to pass to a frontend, or storing constructed filters for audit logging — that capability does not yet have a stated equivalent.

---

What I'd recommend doing with this issue

Your four questions are good, but question 3 in particular needs a direct answer from the Prisma team that isn't in the published blog post — specifically, whether multiple chained .where() calls compose with AND semantics or whether later calls override earlier ones. That's the crux of whether your multi-layer filter composition pattern (service → domain → user input) survives the migration at all.

Given this is genuinely early and the team has stated they're actively soliciting design feedback before Prisma Next becomes Prisma 8, I'd suggest:

1. Keep the four questions but add the explicit AND/override question for chained .where() calls — that's the most actionable unknown.
2. Ask specifically whether collection methods can be composed/combined with each other dynamically at runtime (e.g., conditionally calling .forUser() only if a userId is present), since your real-world need is conditional composition, not just predefined named methods.
3. If you want closer engagement, the Prisma team has an active #prisma-next-discussions channel on Discord specifically for this kind of extension/design feedback — cross-posting there may get a more direct answer on the AND/override semantics than a GitHub issue alone, since that's exactly the kind of pre-release design decision they're soliciting input on right now.

This is exactly the kind of feedback that's useful at this stage — you've identified a real production pattern that the current published examples don't explicitly address, which is more valuable than a vague "will this support X" question.

[DarkKingpro10]

Thanks, everyone; you've really put my mind at ease.
I also have to give credit to @soosho and @logusivam for providing examples that helped me better understand how dynamic filters would work and especially for demonstrating that it's an improvement over the current system.

I'll leave the discussion open in case anyone wants to contribute or so GitHub can close it automatically.