English for Ktor Developers

Ktor is JetBrains’ asynchronous framework for building servers and clients in Kotlin, built directly on coroutines rather than a thread-per-request model. Its vocabulary — “pipeline,” “plugin,” “call,” “route extension function” — differs enough from Spring or Express that teams moving to Ktor often talk past each other in code review. This guide covers the English used when discussing Ktor code with a team.

Key Vocabulary

Pipeline — the ordered sequence of interceptors an application call passes through (routing, plugins, handler); understanding pipeline order explains why one plugin sees a request before another. “Your authentication plugin needs to sit earlier in the pipeline than the logging plugin, or you’ll log requests that never even got validated.”

Plugin (formerly “feature”) — a reusable unit of cross-cutting behavior (compression, content negotiation, call logging) installed into the application, roughly Ktor’s equivalent of middleware. “Instead of writing that header logic by hand in every route, install it once as a plugin and it applies application-wide.”

Call — the ApplicationCall object representing a single request/response pair, carrying both the incoming request and the outgoing response as it moves through the pipeline. “Don’t read the body twice from the same call — the request stream gets consumed the first time you call receive().”

Route extension function — a route defined as a Kotlin extension function on Route, letting teams split routing across files without a central controller class. “Split the user routes out into their own extension function on Route — it keeps Application.module() from turning into a five-hundred-line file.”

Content negotiation — the plugin and mechanism for automatically serializing and deserializing request/response bodies (JSON, XML) based on Content-Type and Accept headers. “Once content negotiation is installed with kotlinx.serialization, you can return a data class directly and skip the manual Json.encodeToString call.”

Suspend function handler — a route handler written as a suspend function, letting it call other coroutine-based code (database queries, HTTP clients) without blocking a thread while waiting. “Since the handler’s a suspend function, awaiting the database call doesn’t tie up a worker thread — that’s the whole point of building on coroutines instead of a thread pool.”

Common Phrases

• “Where in the pipeline does this plugin get installed — before or after routing?”
• “Is this cross-cutting concern a good candidate for its own plugin, or is it route-specific enough to stay inline?”
• “Are we reading the call’s body more than once anywhere in this handler?”
• “Should we split this route extension function out once it grows past a screen of code?”
• “Does content negotiation cover every content type this endpoint needs, or do we need a custom converter?”

Example Sentences

Reviewing a pull request: “This suspend handler is calling a blocking JDBC driver directly — wrap it in withContext(Dispatchers.IO) or you’ll starve the coroutine dispatcher under load.”

Explaining a design decision: “We pulled authentication into its own plugin so every route gets it automatically, instead of remembering to call a check function at the top of each handler.”

Describing an incident: “The outage traced back to a plugin installed after routing instead of before it — requests were reaching handlers before the rate limiter ever saw them.”

Professional Tips

• Say “install a plugin” rather than “add middleware” when talking Ktor specifically — it signals familiarity with the framework’s own terminology to reviewers.
• When debugging odd behavior, ask “what order are the plugins installed in?” — pipeline order is the first thing experienced Ktor engineers check.
• Use “suspend handler” to be precise about why a route doesn’t block a thread — it distinguishes Ktor’s model from traditional blocking servers in review comments.
• Call out route extension functions explicitly when proposing a file split — it’s the idiomatic Ktor pattern, not just “moving code to another file.”

Practice Exercise

1. Explain in two sentences why plugin installation order can change request behavior.
2. Write a one-sentence code review comment flagging a blocking call inside a suspend handler.
3. Describe, in your own words, what content negotiation does for a Ktor application.