Hello! I’ve watched this <Building applications wi...

# arrow

[starke]

Hello! I’ve watched this

Building applications with Kotlin and Arrow.kt in style▾

video like 3 times now and really like the functional style of the sample project.

As I’m trying to adapt my project to work more like that sample, I keep running into difficulties that I think are a result of me using kotlin-inject to supply the dependencies.

I’m starting to think that using a DI library may not be super compatible with the way that ResourceScope works, because I can’t really figure out a good way to provide my database dependencies as a Resource when using kotlin-inject to provide the dependency instances.

Does anyone have any guidance on whether it makes sense to use something like kotlin-inject alongside the arrow Resource management stuff? Any insight would be helpful! Thanks 🙂

[Riccardo Cardin]

Hey. In my experience both in Kotlin and Scala, when you approach a functional style of programming using a framework or a library like ZIO, Cats Effect, or Arrow arrow, it isn't easy to use a DI framework either. They do not integrate.

Both need to have control of the object lifecycle because, through it, they guarantee some specific features.

In the case of resource management, you need to instrument Arrow to understand how to obtain and release the resource.

I think you should create all the stuff at the very beginning of your application. Let me know if you need some reference applications.

[simon.vergauwen]

Hey @starke,
It's possible to mix-and-match but ResourceScope doesn't mix with DI since they overlap in features like @Riccardo Cardin mentioned.

If you're interested in Resource, here is 2 talks of me talking about it.
• https://nomisrev.github.io/grateful-shutdown-with-structured-concurrency/
• https://nomisrev.github.io/graceful-resource-handling-using-structured-concurrency-in-kotlin/
And an example repo, https://github.com/nomisRev/ktor-arrow-example

[simon.vergauwen]

lol at my typo in the url 🤣

[starke]

awesome I’ll check those out - thank you both!

[starke]

I did get everything working nicely, but now as my application is growing the manual dependency injection is getting a little unwieldy.

so I would definitely be interested in seeing any reference applications you could point me to @Riccardo Cardin!

maybe they solve this in a more elegant way than what I’m thinking about doing.

[simon.vergauwen]

What kind-of APIs would clean-up your manual dependency injection @starke? I personally found I end up with the similar amount of boilerplate then let's say Spring.

[starke]

Yeah I’m not really concerned about the amount of boilerplate. So far the manual injection is actually a lot simpler than using a framework!

Just wondering if there are any common patterns or suggested ways to modularize my dependencies so it’s not all piled into one Dependencies file/class 🤔

I don’t have a lot of dependencies yet, but am considering doing something like this to modularize the DI a bit more.

class Dependencies(
    val healthChecks: HealthCheckRegistry,
    val persistence: PersistenceModule,
    val services: ServicesModule,
    val externalClients: FooModule,
)

class PersistenceModule(
    val dataSource: HikariDataSource,
    val database: Database,
)

class ServicesModule(
    val fooService: EventsService,
    val barService: GroupsService,
)

class FooModule(
    val bar: Bar,
)

Maybe overkill though? I may just be stuck in a dagger-style DI mindset 😆

This will be my first project that implements DI without a framework, so I’m just looking for whatever guidance y’all may have. Thanks!

[starke]

And here’s an example of what I have inside one of the module classes (PersistenceModule in this case)

suspend fun ResourceScope.newPersistenceModule(
    env: Environment.DataSource,
): Dependencies.PersistenceModule {
    val hikari = newHikariDataSource(env)

    return Dependencies.PersistenceModule(
        dataSource = hikari,
        database = newDatabase(hikari)
    )
}

private suspend fun ResourceScope.newHikariDataSource(
    env: Environment.DataSource,
): HikariDataSource = autoCloseable {
    HikariDataSource(
        HikariConfig().apply {
            jdbcUrl = env.url
            username = env.username
            password = env.password
            driverClassName = env.driverClassName
        }
    )
}

private suspend fun ResourceScope.newDatabase(
    dataSource: DataSource,
    adapters: DatabaseTypeAdapters = DatabaseTypeAdapters(),
): Database {
    performMigrations(dataSource)

    val jdbcDriver = closeable { dataSource.asJdbcDriver() }
    return Database(
        driver = jdbcDriver,
        fooAdapter = adapters.foo,
        barAdapter = adapters.bar,
    )
}

private fun performMigrations(dataSource: DataSource) {
    val migrationFilesLocation = Paths
        .get("server", "build", "resources", "migrations")
        .toAbsolutePath().toString()

    Flyway.configure()
        .dataSource(dataSource)
        .locations("filesystem:$migrationFilesLocation")
        .validateMigrationNaming(true)
        .validateOnMigrate(true)
        .load()
        .migrate()
}

[simon.vergauwen]

That is exactly what I am doing, but I am missing an example

[simon.vergauwen]

I split it up arbitrarily however I need it

[starke]

ah good to know, thanks! yeah I haven’t found any examples online of a more complicated project that does manual DI

[simon.vergauwen]

I worked with a lot, but nothing public

[starke]

your videos and ktor example repo were very helpful in getting the basics set up though

[Riccardo Cardin]

Hey. Maybe the problem is that your application is growing too much. Did you consider to split it?