:question: :mega: We are going to develop and expa...

# ktor

[cy]

❓ 📣 We are going to develop and expand ktor Locations (Type-Safe routing https://ktor.io/servers/features/locations.html). One of the directions to improve is Kotlin Multiplatform. The most obvious way of migration to MPP is to use kotlinx.serialization in locations. Due to the limited reflection capabilities of non-JVM targets, there are things that not so easy to implement. On the other hand, there are questionable features that may lead to issues. One of the problematic features is nested location classes and nested location objects. 

What we are thinking of to change:
• a nested location class should always have a property of the outer class or object
• nested objects in objects are not allowed
The motivation for the first point is the fact that a location class nested to another, makes no sense without the ability to refer to the outer class. Consider the following example:

@Location("/api/{version}")
class Api(val version: Int) {
   @Location("/user/{id}")
   class User(val id: String, val api: Api = Api(1)) {
     // here API presence looks required, 
     // otherwise, there is no way to find a version value
     // so now we demand the api parameter to exist
   }
}

The other point is that one can't just move a nested class outside without additional manual changes:

@Location("/root")
class Outer {
   @Location("/child")
   class Child // it is tied to /root/child path
}

@Location("/child")
class Child // this is tied to just /child

@Location("/child2")
class Child2(val outer: Outer) // -> /root/child2

The cause of the second change is that objects should be symmetric with classes, and one can't add a constructor property to an object. The unfortunate consequence is that one can't write like this anymore:

@Location("/api")
object Api {
   @Location("/info")
   object Info 
}

Should be migrated to the following:

@Location("/api")
object Api {
   @Location("/info")
   class Info(val api: Api = Api)
   // the api parameter is required, weird isn't it
}

The question is: do these changes affct many, does anybody use structured locations with nested objects?

[spand]

We dont use nested locations but please make a github issue about both locations and nested locations new designs.

Also, I made this issue a couple years back that would be nice to keep in mind: https://github.com/ktorio/ktor/issues/260

[cy]

Created https://github.com/ktorio/ktor/issues/1660

[christoph.pickl]

to be honest: stating something like "[...] limited [...] capabilities of non-JVM targets [...]" raises some concerns in me in regards to the general strategy of trying to cover all platforms, rather than to be focused on a single (major?) platform, JVM that is.
i wonder how many (non-JVM) people are going to use ktor as their web framework?
i might be missing a point here, true. and this might lead to a totally off-topic general discussion, i agree. still this is for me evidence that jetbrain's overall strategy could be a risky thing... 🤔

[cy]

@christoph.pickl Well, the reasons are not only technical, but right. We also consider future code maintenance that is better in spite of a bit of bolierplate.

[cy]

Also, I'd say it's too risky to rely on a single platform. I don't say that we believe that JVM may disappear quickly, but it is possible. People are already looking for opportunities.

[spand]

Regardless it seems the course has been set and ship sailed.

[christoph.pickl]

thanks sergey for your explanation, appreciate that.

and yeah, ship already sailed, fair point 🚢 😆