How do you decide whether to expose a generic `where` input with nested AND/OR/NOT on a GraphQL list field?

## What the choice actually is A curated filter input publishes the predicates you have decided to support. A generic `where` input publishes a **query language**: ```graphql input StringPredicate { eq: String, in: [String!], contains: String } input FloatPredicate { eq: Float, gt: Float, gte: Float, lt: Float, lte: Float } input ReadingWhere { and: [ReadingWhere!] or: [ReadingWhere!] not: ReadingWhere stationName: StringPredicate temperatureC: FloatPredicate recordedAt: DateTimePredicate } ``` That is recursive by construction, and the recursion is the point of the design and the source of every cost below. The decision is not a style preference; it is a decision about who absorbs the open-ended work, and it is close to irreversible. ## The costs, in the order they bite **Every expressible combination becomes a supported contract.** With curated arguments, the set of things a client can ask for is finite and you approved each one. With a `where` tree it is unbounded, and you approved it in aggregate. You cannot deprecate a *combination*: `@deprecated` attaches to an input field, not to "`or` nested three deep under `not`". The only granularity you have is removing a field from the predicate input, which breaks every document that used it in any position. **Capacity planning loses its object.** The question "what access paths must the storage engine serve?" no longer has a finite answer. Nobody can enumerate the queries to index for, so index coverage becomes reactive: you find out which shapes are unserved when one of them is already in production. A dashboard whose `or` branch defeats every index does not fail — it returns an 8,400-row scan in three seconds, every thirty seconds, and looks like a capacity problem rather than a design one. **Static cost analysis loses its grip.** Limiters that score a request before executing it work from the selection set and its arguments. A predicate tree makes the score depend on the *shape and selectivity* of an argument value rather than on the fields selected, and selectivity is not knowable statically. Whatever weights you assign, the honest position is that a `where` tree is much harder to score than a fixed argument list, which is why teams that ship one usually end up enforcing timeouts and row caps instead. **Introspection becomes a promise you may not keep.** This is the subtle one. A curated schema that omits a filter tells the truth: that query is not available. A generic `where` shows every field crossed with every operator, so a client discovers a filter, writes it, ships it, and meets a timeout. Advertising a capability you serve badly is worse than not advertising it, because the client has already built on it. **Input depth is a surface of its own.** Recursion means a caller controls the depth of the *argument value*, not just of the selection set. Depth and complexity limiters are commonly written to walk the selection set, so a deeply nested predicate tree can slip past a limit that looks like it should have caught it. If you ship a `where`, the input-value depth needs an explicit bound of its own. ## When it is nevertheless right When the consumers are few, internal and trusted — an analytics surface, an internal tool, one team's reporting client — the flexibility genuinely saves months of one-off filter fields. When the storage engine really does serve arbitrary predicates at the scale involved. When the schema is generated from storage anyway, and its whole value proposition is that the client can ask for anything. And when you can make the predicate set finite again by other means: registering the documents that are allowed to run turns "unbounded query language" back into "a reviewable list of queries", which is the single most effective way to have both. ## The middle paths worth naming Curated per-field operator inputs with no `and`/`or`/`not` recursion: `temperatureC: FloatPredicate` gives clients the operators they keep asking for while keeping the predicate set flat and enumerable. Or allow one level of `or` and no nesting. Or expose the generic surface on a separate, clearly-scoped field for the analytics consumer, and keep the product-facing list fields curated — the two audiences have different contracts and different failure budgets. ## The principal framing Say plainly that this transfers work from schema authors to operators, permanently, and that the transfer is hard to reverse: once documents exist, you need usage evidence from a registry before you can remove any part of the surface, and there is no evidence at all for the combinations nobody has run yet. Decide it on the number and trust level of the consumers, on whether the storage engine can honour what introspection will advertise, and on whether you have a mechanism — registered documents, a hard row cap, a timeout — that makes the unbounded surface bounded again in practice. A candidate who answers "it depends on the use case" and stops has not answered; the interviewer wants the specific things it depends on.