I'm just starting out with ktor so maybe I'm missing something obvious, but I'm wondering how I can go about structuring more complex endpoints across classes, and the "Extracting Routes" code sample appears to be identical to the starter Hello World above it. https://ktor.io/servers/structure.html 🤔 What I'd like would be a way to have a class (an implementation of

PipelineInterceptor

?) handle processing for a given path.

Do you mean to have several methods per class handling each method one route? Or do you mean to have a class per route?

I'd be fine with a class per route. I'm tinkering with the guice sample, but my goal is to have a nice way of packaging up logic that isn't so tied to lexical scoping. That's great for small services, but I'm trying to feel out how it scales complexity wise.

So the problem with replicating as the

HelloRoutes

from the dice example is that you have to declare routes in code instead of with methods? Your objective is being able to call those methods/routes directly for testing?

No, I think the HelloRoutes way is manageable, it's just a bit clumsy. I'm totally fine with declaring routes in code rather than via annotations. My objective is to be able to package up complexity (and use DI to avoid having to grow the lexical scope). It's possible this is a bad idea for reasons I haven't thought of yet, but it seems like I want to be able to do something like

get("/foo", someInstance)

.

Uhm. AFAIK once you reach the init constructor, the previous constructor (the one with the injection) has already been called. So every dependency should be instantiated already. And be already part of your object as a final member. As long as you declare other properties before the init you should be okay. But not sure if that’s your concern. Since I don’t know why it is thread unsafe. --- What about?

class HelloRoutes @Inject constructor(application: Application, @Named("hello-message") message: String) {
    init {
        application.routing {
            get("/") { root() }
        }
    }
    
    suspend fun PipelineContext<Unit, ApplicationCall>.root() {
        // ...
    }
}

Ah, if

init

runs after the write barrier for final fields, then it should be safe.

Don’t worry. Those questions totally make sense. So feel free to ask as much as needed! Also I’m going to review the structure page to give more information and to provide guide examples

The issue I have with solely using extension methods as a means of structuring things is that it still ultimately depends on lexical scope as a means of sharing resources. The

HelloResource

-style piggybacking on top of Guice's instantiation to register with the

Application

is a little unintuitive IMO but nothing I can't get used to, and it certainly has the real benefit of being very explicit. You have somewhere to put breakpoints, etc, and that's always a problem with annotation-based approaches.

Aha. Yeah I agree that initially is a bit strange when coming from other approaches. It is more explicit and relies less on reflection for doing the job, so it is less magical. If after trying it a bit you have ideas, suggestions or feedback; let us now. --- Also if you don’t want to use extension methods, you can do something like this so you can extract the body handler of your routes:

init {
    application.routing {
        get("/") { root(call) }
    }
}

suspend fun root(call: ApplicationCall) {
    call.respondText("HELLO")
}