question for the NoSQL/Tempest experts.. I’m getti...

# squarelibraries

[james]

question for the NoSQL/Tempest experts.. I’m getting into the world of NoSQL data modelling and I’ve just discovered https://cashapp.github.io/tempest/

I’ve built and almost finished a Kotlin backend (everything except DB), but I don’t have my DynamoDB setup yet, and I’m wondering if this approach sounds reasonable:
• build mappers for my data classes (or modify existing ones to conform to Tempest requirements)
• and then create my DynamoDB tables, only after I’ve built out the Tempest interfaces/data classes
I’ve been dealing with RDBMS for ~20 years, and while NoSQL is familiar to me, creating a new data model for it from scratch is not. I am determined to learn though, and I want to get this right.
I’ve read the Tempest docs (incl. the links to Alex DeBrie’s blog) which has been incredibly helpful in my understanding so far.. it just feels like I’m stuck with a bit of analysis paralysis right now, so hoping someone here might have some guidance.. are my steps in roughly the right order? is there a better approach?

[Andrew Alexander]

👋 I’ve invited the Tempest maintainer to chime in, he’s waiting on confirmation from JetBrains and then will jump in the thread here.

[james]

thanks Andrew, appreciate it 🙏

[Tim Kye]

Hey James, I'm the current maintainer of tempest but I am not the original author. I'll try to give you the short version, feel free to probe with questions.

Tempest is built with the "Single Table Pattern" in mind (which is now finally recommended by the docs).

So first off: only make 1 table for your app! Make the PK and SK generic fields. That means its also probably fine to create your table right away, because until you get to GSIs (which can be added to an existing table) all your tables should have the same starting schema.

Second: don't think in terms of mappers. You will have a primary class (annotated with @DynamoDbBean that represents a "row". This class will be the union of all of your types. This class may have "converters" on its fields, which handle mapping for individual fields. A common one for us is _@get:DynamoDbConvertedBy_(InstantToEpochMillisTypeConverter::class) to map Instants. After this you will have data class
's for each type. You can add these as you add types.