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

Term	How to use it
procedure	”Add a getProfile procedure to the user router.”
query	”Use a query for any read-only data fetch.”
mutation	”Expose data changes as mutations, not queries.”
context	”Thread the db client through context, not procedure arguments.”
end-to-end type safety	”Rename a server field and the client breaks at compile time — that is end-to-end type safety.”

Navigating Complexity: A Guide to tRPC Terminology

tRPC isn’t just a set of code; it’s a way of thinking about building robust, type-safe APIs. Successfully communicating those ideas – especially when collaborating with others – requires a specific vocabulary and phrasing. For non-native English speakers, this can feel particularly challenging, so let’s break down some key terms and how to discuss them confidently. Understanding the nuances around routing, end-to-end type safety, and the underlying architecture of tRPC will dramatically improve your ability to participate in technical discussions and contribute effectively.

Let’s consider a common scenario: a code review comment. Imagine receiving this feedback on a PR proposing a change to the routing logic: “This route handler could benefit from clearer documentation outlining its expected input types and potential error scenarios. Consider adding assertions for stricter type enforcement.” The key here isn’t just translating the words, but understanding why that phrasing is used. “Clearer documentation” implies a need for greater precision – a crucial element of professional communication. Similarly, “stricter type enforcement” refers to leveraging tRPC’s inherent benefits in guaranteeing data integrity. It’s about conveying not just what needs to be done, but how it aligns with the core principles of tRPC. Phrases like “leveraging tRPC’s inherent benefits” demonstrate an understanding of the technology at play – a sign of technical proficiency and engagement.

Another common situation is discussing router configuration. Imagine a Slack message: “We need to adjust the route’s latency threshold to improve response times for our mobile users.” The phrasing here focuses on impact – “improve response times.” This isn’t just about speed; it’s about user experience, and communicating that impact effectively is vital. Using terms like “latency threshold” demonstrates familiarity with a technical detail, while framing the discussion around “mobile users” connects it to a tangible outcome. It’s crucial to avoid overly simplistic language when discussing complex systems.

Finally, let’s consider describing the concept of end-to-end type safety. Explaining this to someone unfamiliar with tRPC might involve saying: “tRPC ensures that every piece of data – from the initial request to the final response – is strictly typed. This eliminates potential runtime errors and provides a much higher level of confidence in our API’s correctness.” The phrase “strictly typed” is particularly important; it highlights the core benefit compared to traditional approaches where type checking might be limited or absent. It’s about emphasizing that tRPC doesn’t just support type safety, it enforces it throughout the entire system.

// Example: Illustrating type enforcement with a simplified tRPC request
// (This is conceptual - actual tRPC code would be more complex)
const requestData = {
  userId: "12345",
  name: "John Doe",
  age: 30, // Type enforced here!
};

// Assuming 'validateRequest' function checks types before processing.
// validateRequest(requestData); // Example of type validation in action

By focusing on clear and precise language, understanding the why behind the terminology, and using phrases that align with tRPC’s core principles, non-native English speakers can confidently participate in technical discussions and contribute to successful development projects. Remember, effective communication is just as important as the code itself.