Does anyone know if the new <DI feature> introduced in Ktor 3.2.0 will replace the need for using A...

# arrow

[Kjartan]

Does anyone know if the new DI feature introduced in Ktor 3.2.0 will replace the need for using Arrows SuspendApp with Ktor lib?

[simon.vergauwen]

Hi @Kjartan,
You can already achieve the same today without 3.2.0, it was not explicitly mentioned in the release post but some fixes related to Structured Concurrency during graceful shutdown now allow to achieve the same as SuspendApp fixes. You can also achieve the same with Koin. but Ktor's DI will also allow it.

SuspendApp is still useful, with or without Ktor but if you want to get rid of SuspendApp then I can help you figure it out ☺️ I have a couple of examples on my personal github as well.

[simon.vergauwen]

Do you think a document about this use-case, graceful shutdown and closing dependencies is missing from the Ktor website?

[Kjartan]

The example in release notes was nice with an example of using cleanup and was what lead me to this question. I'm currently using SuspendApp and it has worked nice, but with the new DI features in Ktor I was thinking about doing some refactoring towards using Ktor DI. I think it would be great with an update of the Ktor doc too, haven't looked too closely there yet, just read the release notes and got curious 🙂

[simon.vergauwen]

It’s more a matter of preference I’d say. You can currently also just do monitor.subscribe(ApplicationStopped) { closeable.close() }, beware of the order of closing. cleanup and ResourceScope do this automatically. Koin also supports onClose, and it has compile-time checks which Ktor doesn’t have atm.

We should probably add cleanup into server-core instead of just the DI module. If you want feel free to create a YT issue, or I can do it later ☺️

[phldavies]

(A little late the the discussion) I think an important distinction between choosing Ktor or SuspendApp to handle cleanup is whether you consider the Ktor server to be the service or part of the service. An example might be a microservice that has both an HTTP interface and a Kafka interface. Having the HTTP serving component manage the lifecycle of the Kafka consumers just doesn't quite feel right - although it's a perfectly viable approach.

[simon.vergauwen]

Great point, but when SuspendApp was build most of the required behavior was not yet implemented in Ktor 😅 (Neither did Spring). Currently both support this functionality.

> HTTP serving component
This doesn't feel correct to me either 😅 Application is not related to HTTP, or Routing. It's tightly coupled for convenience but they're isolated components. From coroutines POV Application is just SupervisorJob + state (environment). That is also reflected in how it shuts down.

Anyway, I personally prefer SuspendApp since it's a proper abstraction, and makes embeddedServer just another coroutine. I wish it was part of the KotlinX ecoystem and then Ktor could redefine this logic purely as a composition of coroutines.

[phldavies]

From a quick glance, other benefits of SuspendApp (+ ResourceScope) is the ability to delay shutdown to allow for infra such as Load Balancers to unregister before the service starts rejecting requests.
And neither cleanup or monitor.subscribe allow for suspendful resource releasing.

I do like the idea of using Application as the core of a service and the http facet becoming just another coroutine - it would be nice to have a single Application with multiple ports too (to allow for scenarios like dedicated metrics/management ports, or separating ports for HTTP/GraphQL/gRPC/kRPC etc)

[simon.vergauwen]

> And neither cleanup or monitor.subscribe allow for suspendful resource releasing.
Planned, but breaking changes are delaying this to next major version.

[simon.vergauwen]

> do like the idea of using Application as the core of a service and the http facet becoming just another coroutine - it would be nice to have a single Application with multiple ports too (to allow for scenarios like dedicated metrics/management ports, or separating ports for HTTP/GraphQL/gRPC/kRPC etc)
What do you mean? That's already possible today 😎

Untitled.cpp

[simon.vergauwen]

Sorry, doesn't even need a custom route selector. Exist out of the box updated the snippet.