Application Setup

## The two entry points A Ktor server is an engine plus one or more *modules*. Ktor gives you two ways to assemble them, and interviewers ask about the difference because it decides how the service is configured in production. ### embeddedServer — configuration in code ``` fun main() { embeddedServer(Netty, port = 8080, host = "0.0.0.0") { module() }.start(wait = true) } ``` `embeddedServer` is a function that takes an *engine factory* (`Netty`, `CIO`, `Jetty`, `Tomcat`) as its first argument, some connector settings, and a lambda that runs with `Application` as its receiver. It returns a server object you can `start()` and `stop()`. `wait = true` blocks the calling thread until the server stops; `wait = false` returns immediately, which is what tests want so they can issue requests and then shut the server down. Everything is visible in Kotlin: the port is a literal or a variable, the module is a direct function call, and nothing is resolved by name at runtime. That makes it refactor-safe and IDE-navigable. ### EngineMain — configuration in a file Each server engine artifact ships an object called `EngineMain` with a `main(args)` function. You point your build at it: ``` application { mainClass.set("io.ktor.server.netty.EngineMain") } ``` and put the settings in `src/main/resources/application.conf`: ``` ktor { deployment { port = 8080 } application { modules = [ com.example.ApplicationKt.module ] } } ``` The format is HOCON (Human-Optimized Config Object Notation), the Typesafe Config format. Ktor also supports `application.yaml` when the YAML config artifact is on the classpath. `EngineMain` loads that file, builds the engine, and then resolves every entry in `ktor.application.modules` **by fully-qualified name** and invokes it against the `Application`. That name is the part people get wrong. A top-level function `fun Application.module()` declared in `Application.kt` compiles to a static method on the class `ApplicationKt`, so the reference is `com.example.ApplicationKt.module`. Misspell it and the server fails at startup with a class-not-found style error rather than a compile error — the cost of late binding. ## Why the choice matters **Reconfiguration without a rebuild.** With `EngineMain` the port, the connector, the log level and even which modules are enabled are data. A container image can be reused across environments and driven by config. With `embeddedServer` the same change is a code change. **Environment overrides.** File-based setup composes naturally with HOCON substitution such as `port = ${?PORT}`, which takes the value from an environment variable if it is set and leaves the previous value otherwise — exactly the shape a PaaS or Kubernetes deployment wants. **Tests.** Test code overwhelmingly uses code-based startup, directly or through Ktor's test host, because it needs an ephemeral port and an in-process lifecycle. A common production layout therefore ships `EngineMain` for the real deployment while tests call the same `Application.module()` function through `embeddedServer` or the testing DSL. Because a module is just an extension function on `Application`, both paths reuse it unchanged. **Hybrid.** The two are not exclusive. You can start `embeddedServer` and still read `application.conf`, since the config is available through the application environment; conversely `EngineMain` accepts command-line arguments that override file values. ## What a good answer includes Say that both end up at the same `Application` object, name HOCON/`application.conf` as what `EngineMain` reads, mention `ktor.deployment.port` and `ktor.application.modules`, and give the practical rule: file-based for deployment flexibility, code-based for tests and single-purpose tools. Note the tradeoff honestly — the config file buys you runtime flexibility and costs you compile-time checking of module references.