Usage in Server Side Swift with Vapor

[madsodgaard]

Hey, awesome library!

I am trying to figure out whether it is possible to use this library in a Vapor project for server-side-swift. Vapor is built with it's own way of defining dependencies. So, maybe it's just not optimal trying to fuse the two concepts. But, perhaps you have some ideas!

One concrete situtation I've encountered is the use of databases with Vapor's Fluent library. There we have a Database protocol defining a single connection to a database. This was my first attempt at implementing this is a dependency with this library:

public enum DatabaseKey: DependencyKey {
    public static var liveValue: any Database {
        @Dependency(\.application) var app: Application
        return app.databases.database(logger: Logger(label: "database"), on: app.eventLoopGroup.any())!
    }
}

extension DependencyValues {
    public var database: Database {
        get { self[DatabaseKey.self] }
        set { self[DatabaseKey.self] = newValue }
    }
}

The problem with this is that I could ever only get one database connection, as the Database would be "cached" as a dependency. Not great for concurrency. I would like each call to database to create a new object/connection. So instead I defined it as a closure that returns a database:

public enum DatabaseKey: DependencyKey {
    public static var liveValue: () -> any Database {
        @Dependency(\.application) var app: Application
        return {
            app.databases.database(logger: Logger(label: "database"), on: app.eventLoopGroup.any())!
        }
    }
}

Also, in other dependencies where I want to use a Database I also have to define them as a closure, otherwise they would also all just use the same Database object/connection. Alternatively I could use @Dependency directly in the .live body instead of passing a database as a parameter, but then I am leaking some information about how to manage dependencies into another "library".

struct UserRepository {
    var findAll: () async throws -> [UUID]
    
    static func live(db: Database) -> Self {
        .init {
            return [.init()]
        }
    }
}

enum UserRepositoryKey: DependencyKey {
    static var liveValue: () -> UserRepository {
        {
            @Dependency(\.database) var db: Database
            return .live(db: db)
        }
    }
}

extension DependencyValues {
    var userRepository: UserRepository {
        get { self[UserRepositoryKey.self]() }
        set { self[UserRepositoryKey.self] = { newValue } }
    }
}

Is there any alternative/better solution than this?

[mbrandonw]

Hi @madsodgaard, while we haven't specifically explored using the dependencies library in Vapor (though we plan on it soon), we do think it should work quite well. In general, server frameworks are a great example of “single entry point systems”, which this library excels at.

However, we have started using this dependencies library on our site, which doesn't use Vapor but we were able to model a database client dependency just fine. Rather than holding a connection to the database directly in dependencies, we hold a connection pool for the database. Would that help your situation?

[madsodgaard]

Hey @mbrandonw, thanks for quick response! Would definitely fix the issue if I used a connection pool directly instead. Unfortunately, Fluent (Vapor's ORM) uses Database for almost everything database-related. For example if I need to save a user model: myUser.save(on: myDb). So, if I still want to use Fluent, I basically need a Database instance in my services. Perhaps the closure version is the way to go, for now at least. Do you see any issues with it when using this library?

[mbrandonw]

Ah ok, that's a bummer.

There's nothing wrong with using a closure as far as the library is concerned. And so if it is OK for you to construct many Database instances, then I think it's fine to do.

[nashysolutions]

@mbrandonw the situation has evolved slightly vapor/vapor#3086

[mbrandonw]

Hi @nashysolutions, that issue has nothing to do with this library. You can remove swift-dependencies from the package and it still does not compile. The real issue is that you are trying to compile a version of Vapor that is 3 years old in Swift 5.9, and something about Swift must have changed to break how Vapor is using split.

[nashysolutions]

haha that was the default when following along with their quick start guide about 6 months ago vapor new hello -n
thanks for your time