English for tRPC Developers

tRPC is growing rapidly in TypeScript full-stack teams, and its vocabulary has a distinctive flavour that blends backend API concepts with TypeScript type-system terminology. If you joined a team using tRPC and English is not your first language, you may find yourself unsure how to describe a “procedure,” explain “end-to-end type safety,” or ask about “context” in a code review without sounding vague. This guide gives you the precise vocabulary and the natural English phrases that experienced tRPC developers use every day.

Key Vocabulary

Procedure The fundamental building block of a tRPC API. A procedure is a single callable endpoint defined with .query() or .mutation() (or .subscription()). It replaces the concept of a REST route or a GraphQL resolver. Example: “I added a getUser procedure under the user router that fetches a user by ID from the database.”

Query A tRPC procedure defined with .query() that reads data without side effects. Equivalent to an HTTP GET in intent. Queries should be idempotent — calling them multiple times has the same result. Example: “The listPosts procedure is a query because it only reads from the database and never modifies state.”

Mutation A tRPC procedure defined with .mutation() that changes server-side state — creating, updating, or deleting data. Equivalent in intent to HTTP POST, PUT, PATCH, or DELETE. Example: “We exposed deleteComment as a mutation since it permanently removes a record from the database.”

Router A collection of procedures grouped under a common namespace. Routers can be nested to create a hierarchical API structure. The root router is typically called appRouter. Example: “We split the API into three routers — userRouter, postRouter, and commentRouter — and merged them into the appRouter.”

Context An object created per request (by a createContext function) that is injected into every procedure. Context typically holds the database connection, the authenticated user session, and other request-scoped resources. Example: “The user session lives in the context, so every procedure can check authentication without repeating the auth logic.”

Middleware A function that runs before a procedure’s resolver and can read or modify the context, throw an error, or short-circuit the request. Commonly used for authentication guards and logging. Example: “We wrote a protectedProcedure middleware that throws an UNAUTHORIZED error if no session is present in the context.”

End-to-end type safety The guarantee that TypeScript types flow without gaps from the server procedure’s input and output definitions all the way to the client call site, with no manual type assertions or code generation steps required. Example: “tRPC gives us end-to-end type safety — if I rename a procedure input field on the server, the TypeScript compiler immediately flags the outdated client call.”

appRouter / router inference The single root router exported from the server and used to infer the client’s type. The client type is derived with RouterInputs and RouterOutputs utilities, keeping client types permanently in sync with server definitions. Example: “We export AppRouter from the server package and import it into the client so TypeScript knows the exact shape of every procedure.”

Common Phrases

In code reviews:

• “This logic belongs in a middleware, not inside the procedure itself — extracting it means all protected procedures can share the same auth check.”
• “The mutation is currently returning the entire updated record, but the client only uses two fields — consider trimming the output to reduce payload size.”
• “You are accessing the database directly in the query; thread the db client through the context instead so we can mock it in tests.”

In standups:

• “I finished the updateProfile mutation yesterday and added input validation with Zod; today I am wiring up the client-side call.”
• “I refactored the auth check into a protectedProcedure base so we are not repeating the session guard in every procedure.”
• “I am investigating a type error on the client — the router inference seems to be picking up a stale type from a cached build.”

In documentation:

• “All procedures that require authentication must be built on protectedProcedure, which enforces a valid session via middleware.”
• “Input shapes are validated with Zod schemas attached to each procedure; the inferred TypeScript types are automatically available on the client.”
• “Nest routers by feature domain and merge them into appRouter; avoid placing procedures directly on the root router.”

Phrases to Avoid

Saying “endpoint” when you mean “procedure.” In tRPC, the correct term is “procedure.” Saying “endpoint” is not wrong (tRPC procedures do map to HTTP endpoints under the hood), but it signals unfamiliarity with tRPC’s own vocabulary. In team discussions, use “procedure,” “query,” or “mutation” to be precise.

Saying “type-safe API” to mean end-to-end type safety. A REST API with hand-written TypeScript interfaces is also “type-safe” in a loose sense. The specific value tRPC provides is end-to-end type safety — types flow from server to client without manual synchronisation. Use the full phrase: “end-to-end type safety” or “inferred types across the client-server boundary.”

Saying “the context has the user” when you mean “the context carries the session.” Avoid vague phrasing. In English on tRPC teams, say: “The session object on the context exposes the authenticated user.” This is more precise and shows you understand that context is a structured object, not a simple variable.

Quick Reference