[rco8786]

Is there any example of this ever working in practice in the history of computing? As in, we built a large, stable service with datastore X, but we were forward looking enough to make sure that we only "developed to an interface" and we successfully swapped to datastore Y without significant code changes?

[rmbyrro]

The project I'm currently working uses AWS DynamoDB as primary DB. Since it's proprietary, we ensure the AWS-specific APIs are contained in small and specific part of the codebase.

For instance, to create a "User" we need the PutItem API from DynamoDB [1]. Similarly, to retrieve a "User", there's the GetItem API [2].

Instead of making references to these APIs all over our codebase, we have a single `db-interface` module, which implements `get_user` and `create_user` functions. Each of these functions has an interface: they expect specific arguments with corresponding types. This interface is modeled against our data domain, not DynamoDB data domain quirks.

Inside the `db-interface` module, we implement the conversion from our data domain to Dynamo's. We also have general-purpose functions, like `create_item` and `get_item`, so that `get_user` and `create_user` are pretty much wrappers and only serve the purpose of defining the interface for interacting with the "User" data object.

The rest of our code only interacts with our internal interface, never with DynamoDB APIs directly.

If we were to switch database, we only need to re-implement the general-purpose functions (e.g. `create_item`, `get_item`).

May sound like a lot of work, but it took only a handful of days to implement the entire interface mapping everything we needed from DynamoDB.

Hope this helps clarifying a bit the application of this concept (develop for an interface, not an implementation) in the context of interacting with databases.

[1] https://docs.aws.amazon.com/amazondynamodb/latest/APIReferen...

[2] https://docs.aws.amazon.com/amazondynamodb/latest/APIReferen...

[rco8786]

I understand the concept, I'm just asking if anyone has ever actually done it. DynamoDB has various guarantees, features, edge cases etc that you have to be aware of in your app code, and any DB that you want to switch to will have a different set of guarantees, features, edge cases etc that you will have to support throughout your app. So it's more than just an interface.

[Zababa]

That's interesting. Have you tested this with another DB? The design makes a lot of sense, but I feel like it's the kind of thing that's hard to get right unless you actually test it. At the company I currently work, they switched DB some time ago. They already used interfaces but even that was not enough to make the switch, due to some differences in how the DBs worked.

[rmbyrro]

If you can map the differences in your code and your interface does not leak any implementation detail, you won't have problems.

But if the current database has features that can't be mapped to the new one, the interface won't save you.

Example: DynamoDB has a "time-to-live" feature [1]. You add a specific property to any item with a timestamp and it will auto-delete this item at the timestamp determined.

Few databases will provide this out of the box. If you choose to use it and later need to migrate, you'll have to implement your own kind of "TTL monitor" to perform the same task. The interface can't possibly save you from this.

But this would be an issue whether you decide to use a central interface or not, anyway...

[1] https://docs.aws.amazon.com/amazondynamodb/latest/developerg...

[Zababa]

Thanks, that "time-to-live" feature is a great exemple of what I was talking about. At work if I remember correctly it was something about not being able to read a write just after making it, and having to wait one second. I guess that's the kind of things where you either need people to be very careful when developing the implementation, or have people that have already been burned by that to think about that.