I really don't see how it different using dagger with any kind of project of reasonable size

Also you can move different parts of your route to different classes inject them as multibings and inject in abstract way.

Maybe your app is just very small, so you don't see actual reason to separate different parts of it

I'm kinda curious now haha

Returning to Cody's question, there are many more trivial examples of usage DI with dagger, you building your routing separately, even without multibindings, but you need some actual business logic, implementation of it, storage, database, clients of other services, I don't think you would write it inline in your routing declaration, you should provide it somehow, and this is where you need DI, and inject dependencies to routing declaration I don't say that you must use Dagger for DI, you can write it manually, or use other DI framework based on reflection, but every approach has own tradeoffs. But with Ktor dagger would work exactly the same in most cases

Opposite to trivial example, is having component scoped per request, or per authorized request, so you can build dependency graph per connection/user without need to write it manually and make it even more scalable (Depends on architecture of the app, of course)

Here's a sample of a controller I use dagger with

Your setup also make sense, but it eager to apply, so if this class instantiated it will add itself to routes

@Cody Engel problem with all those extensions is that they at some point start depend on each other explicitly and you pass dependencies between each other, so at some scale on top most level you have an extension with a lot of arguments which deliver them one to another Also it will work until you have one module only

Also not sure how Ktor is different from any other app. If comparing it with Android, Ktor routes is like AndroidManifest, but you need app/server config (like Android Application), you need implementations of routes (like activities). Sure you can bring all things together manually, same as with Android, but to make it maintainable and testable better to keep components simple and reduce cohesion between code, DI make sense. Again properly written manual DI can work at some scale, no doubts. But if you have hundreds of different routes in the app, some connected, some not, they should share configs, database, logging, third party services etc, to connect all this you need a huge class to just create it