Swappable Dependencies

[rhysm94]

Hey, I’ve been thinking about “swappable” dependencies – ones that might change during the runtime of your application.

For example, creating the initial types for an application that uses GRDB is a failable operation. The initialisers for the DatabaseWriter types can fail, as can performing your initial migration(s).

In the past, I’ve just force-tried or fatalError'd this when creating the liveValue – but this means it’s out of our control, and isn’t at all safe. e.g. I’ve seen some crashes when the user’s device is out of space, or once where I mucked up a migration, the app crashed on launch without any meaningful error message for the user.

I know I could handle this by including an ActorIsolated/LockIsolated variable for an Optional value of any DatabaseWriter, and wrapping every method with

try writer.withValue { writer in
  guard let writer else { throw Failure.notMigrated }
  // do something with writer
}

but this approach feels particularly inelegant, having to repeat a lot of boilerplate across every function. To me, there should two entirely separate implementations for the different states – one that always throws, and one that can only be created when passed a non-optional DatabaseWriter. Kind of like classic subtype polymorphism.

I’ve come up with an approach whereby I use an actor to swap between these two different versions of the dependency when the migrate method is called. This migrate method is throwing, so it can handle creating those DatabaseWriter types, as well as performing the throwing migration work.

A repo with sample code is here: https://github.com/rhysm94/SwappableDependencies/

and the actor that I'm talking about is here: https://github.com/rhysm94/SwappableDependencies/blob/main/Sources/SwappableDependencies/DatabaseActor.swift

Ultimately, this gives me control over when the creation and migration happens, and letting me appropriately react to its failure wherever in my app. The downside to this approach is that everything now needs to become async, to interface with the actor, and there's a lot of duplication of the interfaces for my own Database and DatabaseInterface types. There's some additional boilerplate to define a secondary type that can be switched between.

Does anyone have any kind of feedback on this approach? I'd be interested to know how you're all handling dependencies which need to swap their underlying behaviour like this! I would quite like to simplify my approach if possible, and learn how everyone else is doing this.

[groue]

Hello @rhysm94,

Thanks for sharing :-)

Below I'll just share some use cases I met that needed a throwing and varying database access. This is not a direct experience with pointfreeco/swift-dependencies, but it should apply just fine.

• Allowing the app to eventually handle database initialization failure.

  For example, the app might want to display an error message, or to ask user permission before wiping everything and start afresh.

• Database that depends on the signed in user.

  I occasionally derive the database path on disk from the (server environment/user identifier) pair, so that I'm sure that dev/Alice, prod/Alice, and prod/Bob are stored at distinct locations in the "live" app. My goal is to prevent data leak, i.e. make it possible to guarantee that Alice never sees Bob's data, and that dev data never mixes with production data.

  What I like about this setup

  • There isn't any database access until the user is signed in.

  • There is no absolute need to wipe out data on disk when user signs out or app boots on a different server environment. This allows developers and QA testers to frequently switch env/user and avoid downloading a lot of stuff. The only purpose of erasing data is sparing disk space - not preventing data leak.

  • We can make sure that the results of an authorized network access are always persisted in the expected database. If the network access is slow, and the app user has the time to sign out and sign in with different credentials, we still won't see any data leak.

    Wondering whether the results of such a request should be stored on disk after sign out is a different question, and can be addressed when needed. For example, I prefer to let innocuous network requests such as "flag this item as a favorite" proceed to completion, even in the case of a sign out.

In those apps, I also tend to expose a dependency that is not a database connection, but an object that provides database access, just as in your sample application.

[rhysm94]

Hi @groue! Thanks for replying! :)

Yes, I've needed to employ throwable database initialisation/migration, as I've had a couple of instances where I was creating the DatabaseWriter with a try! and I saw at least one user experience a crash as they were out of storage space¹, and I had an issue where a migration I wrote failed in some cases due to an assumption I'd made that a value couldn't be returned as a null from an API... being null from that API, me persisting it as such, and then not dropping any values with null in my migration when I changed the column to be not null 🤦🏻‍♂️. So I've needed to actually handle database initialisation and migration in a throwable context. In my experience, I definitely need to handle the edge cases whereby the database initialisation and migration can fail, as I've seen both happen – causing crashes when I've force try'd them!

The way that the Swift Dependencies library works, I need to handle this state change between having a DatabaseWriter and not having one internally to my dependency. I could have an (any DatabaseWriter)? property that my throwing (init and) migrate method writes a value to upon success, but then every single one of my getFoo, getBar, saveFoos, saveBars methods would need to have a guard let writer else { throw Failure.notMigrated } at the start – which, to me, suggests there's a need for some kind of polymorphism, having one version of the dependency always throwing that error, and one version only being create-able once you actually have a non-Optional DatabaseWriter.

This approach, especially since I use an actor, does mean that basically any endpoint in my dependency needs to be accessed using try await, which leads to some unfortunate syntax when creating an AsyncSequence – for try await value in try await database.observeFoos(), but it's a relatively small price to pay for modelling the dependency like this. I could probably remove some of this by using a LockIsolated from the Concurrency Extras package to hold onto my DatabaseImplementation! I suspect some of the boilerplate in my approach could also be automated away with a macro, too.

Keen to hear other possible means of handling this, and if I've over-engineered my solution in the context of Swift Dependencies 😅

Footnotes

1. I think my app crashing is the least of their concerns in that case, but I'd still like to show an actual error before I then fatalError out, or offer some other solution! ↩