Adopt `sbt-dynamodb` into the Scanamo organisation?

[rtyley]

Scanamo uses the (unfortunately no longer unmaintained) sbt-dynamodb plugin for testing:

https://github.com/scanamo/scanamo/blob/39d293058549b76bb2a9564945cb6f08f3f6e9af/project/plugins.sbt#L1

The plugin still works for the most part, but has at least one long-outstanding issue (https://github.com/localytics/sbt-dynamodb/issues/54 - causes a lot of grief for newcomers to my team at the Guardian!). The plugin is licensed under the permissive MIT license, and the Scanamo GitHub organisation seems like a reasonable place to try to host a fork of it - these projects are both Scala-&-DynamoDB things! How would other maintainers of Scanamo (eg @kailuowang & @davidfurey) feel about that?

What would adopting sbt-dynamodb involve?

• Forking the project into the https://github.com/scanamo organisation
• Updating the documentation & codebase to remove most references to Localytics, other than to properly credit them with the original version of the plugin
• Potential license change to Apache V2, for consistency with Scanamo?
• Setting up CI (GitHub Actions?) & release/artifact-publication process
• Potentially tweaking the codebase with an emphasis on supporting the latest versions of sbt (tho' sbt-dynamodb already supports sbt 1.0, so hopefully nothing to do there for a while?), dropping support for old versions of sbt (eg anything before 1.0).
• Fixing https://github.com/localytics/sbt-dynamodb/issues/54

Alternatives for DynamoDB testing

A couple of things might prompt us to look at alternatives to sbt-dynamodb:

• AWS's DynamoDB Local currently needs a bit of fiddling to get it to run on Apple's M1 architecture (unless you use docker)
• Moving away from AWS's DynamoDB Local altogether, dynalite is a open-source re-implementation of DynamoDB - there's also a 'Testcontainer for it: https://www.testcontainers.org/modules/databases/dynalite/ - I've not used any of these things before, but they sound fairly interesting. Just as with DynamoDB Local, fidelity to the actual AWS DynamoDB service can probably never be 100%.

[kailuowang]

I am not against it. I migrated away from sbt-dynamodb (to using docker) for all my own projects a while ago. That is to say I myself don't have a personal incentive for maintaining it.

I can't speak too much for scanamo development, for application development, docker was more transparent and flexible for me. Another factor is that when I have multiple external application dependencies, it's much nicer to have an unified mechanism to manage their runtime in docker compose than ad hoc solutions like sbt-dynamodb for each one.

[rtyley]

I migrated away from sbt-dynamodb (to using docker) for all my own projects a while ago.

That's interesting! Do you have an example of configuring an sbt project that way - I assume this is using the Docker version of AWS's DynamoDB Local?

[kailuowang]

That's interesting! Do you have an example of configuring an sbt project that way - I assume this is using the Docker version of AWS's DynamoDB Local?

You can find it in https://github.com/iheartradio/thomas/ I set it up in a way so that I can have two local environments: one for integration tests, in which all data are transient (wiped clean every time tests are run), and one with persistent data for a mimic of prod runtime locally. I named them "test" and "dev". They use different ports and data volumes so that tests don't accidentally wipe out dev runtime data. Here is the setup

• A very simple Docker file based off local dynamo with persistent data

• standard docker compose file with env

• env file for "dev"

• env file for "test"

• facility code in buid.sbt (for run docker in sbt)

  • actually runn docker
  • tasks defs here, here and here
  • some sbt alias to help switch between dev and test

• one last thing is make sure that your test code and application code use different port to access dynamo.

Hope that helps but feel free to ask if you have any questions.