Best practices building up a graph in a non-trivial app

[spectrl]

We're using Metro in a brand new KMP-based app that is going to have Android and iOS targets, and was wondering what's the "best" (recommended) way to build up the dependency graph in a non-trivial modularized codebase.

The goal is to have distinct classes, that would live in different modules, that each provide bindings for their respective bits of the app. e.g. ApiGraph, a core module; SearchGraph, a data module that needs a HttpClient provided by the ApiGraph; and then an AppGraph to pull it all together.

Where the AppGraph is also the boundary/entry-point for the KMP shared module, because we're still using Dagger (Hilt) in the Android module.

Currently I've taken some inspiration from Tivi – which uses kotlin-inject – and have something like this:

internal expect interface PlatformAppGraph

internal interface AppGraph :
    PlatformAppGraph,
    ApiGraph,
    SearchGraph,
    ...
    {
}

interface ApiGraph {

    @Provides
    @SingleIn(AppScope::class)
    fun provideApolloClient(appInfo: AppInfo): ApolloClient {
        ...
    }
 }

interface SearchGraph {

    val searchRepository: SearchRepository

    // ApolloClient from the ApiGraph is constructor-injected into my SearchApi class
    @Binds val SearchApi.bind: SearchRemoteDataSource
}

and then this for my actual (Android) graph implementation:

@DependencyGraph(AppScope::class)
abstract class AndroidAppGraph : AppGraph {

    @DependencyGraph.Factory
    internal fun interface Factory {
        fun create(@Provides application: Application): AndroidAppGraph
    }
}

This seems to be working fine, but I guess I'm wondering whether I'm missing anything and maybe I should be using graph extensions instead? And some help with what that might look like 🙏

If it makes a difference I think we would like to do some proper scoping at some point – e.g. @UserScope when logged in and then providing different http client bindings etc.

[bddckr]

On this note, I've been wondering: Why do the following at all when aggregation is done for us automatically based on project dependencies?

internal interface AppGraph :
    PlatformAppGraph,
    ApiGraph,
    SearchGraph,
    ...
    {
}

In my Android project with ~140 modules, I have one @DependencyGraph for the single app this project builds, and one additional graph for some integration tests each. I only have a single case of extending a graph interface: My app-startup logic is doing some kind of generic "app entrypoint handling" in a way that I just need to extend that a bit with the app-specific interface, grabbing some of the resolved dependencies out the graph that way.

tl;dr: Why would you manually list the graph interfaces to extend at all instead of simply using the following and letting aggregation take care of it based on the projects pulled into the compile classpath? 👀

@DependencyGraph(AppScope::class)
internal interface MyGraph { ... }

[spectrl]

Interesting, I've only really used vanilla Dagger (w/ Hilt) and Koin in the past so not really familiar with aggregation but will give it a go!

I was also chatting to Claude (the AI) about it, which suggested using aggregation within layers – e.g. using @ContributesTo for providers in core modules to create a CoreGraph, same for providers in data modules etc. – and then wiring up (composing) the graphs vertically across layers using @Includes.

[spectrl]

It sounds like @BindingContainers from the new release might be exactly what I want! Thanks @ZacSweers

Would be helpful to update/add samples to use some of this stuff and have a more complex reference to look at 🙏