Schema designeasy0-2 years
A `cancelOrder` mutation is designed to return `Order!` directly. A teammate wants to change it to return a `CancelOrderPayload` type with an `order` and an `error` field instead. Why is that a better design, and what does it actually fix?
Returning Order! directly leaves nowhere for a business failure to go — "this order was already shipped and can't be cancelled" isn't a schema-level error, it's an expected outcome the client should be able to read as ordinary data, but a bare Order! return type forces that outcome to either throw an exception (landing in the confusing errors-at-200 array) or silently return something wrong. A payload type (CancelOrderPayload { order, error }) gives that outcome an actual place to live: the mutation always succeeds structurally, and the client checks error the same way it'd check any other field, instead of having to parse an exception out of a list that's also used for genuine failures like timeouts and bugs.
PreviousA GraphQL API has a depth limit of ten levels in production. An attacker sends `orders(first: 1000000) { id }` — one field, one level deep. Does the depth limit stop it, and if not, what does?Next A gRPC call sets a client-side timeout of 2 seconds and calls three downstream services in sequence. Two seconds after the call starts, the first downstream call is still in progress. What happens, and how is this different from each service independently having its own 2-second timeout?