How might we abstract DynamoDB?

[ceilfors]

DynamoDB is an essential part of a serverless architecture in AWS. We read and write data to DynamoDB a lot. Laconia encourages technologists to not be dependent on the cloud in their core application. At the same time, I'm also reluctant to introduce an unnecessary abstraction. Is there a middle ground that covers 80% of user's use cases? How will the API look like if we want to help developers use DynamoDB?

[ljcoomber]

I think your instinct about unnecessary abstraction is sound. Are there concrete use cases people are seeing in the wild where support would help? In most cases I'd imagine a fair amount of implementation specific detail which would be better encapsulated in a custom adapter rather than using a generic framework.

Only thing I could think of is triggering a Lambda on data changes?

[ceilfors]

Read / write

Can you elaborate more on "fair amount of implementation specific detail which would be better encapsulated in a custom adapter"?

My use case is pretty much driven by data storage i.e. repository. As my background on this is driven much by spring-data, I was thinking that we could adopt a similar abstraction for DynamoDB (seems like someone has made the implementation in spring-data for DynamoDB too!)

Apart from repository pattern as an abstraction, what other abstraction can it look like?

Trigger

I don't have personal experience on this one that I don't actually know what people would want. That said, I think a simple adapter would be helpful, just like how we support Kinesis now: https://laconiajs.io/docs/api/adapter#kinesis-app. I'll file a separated issue on this one.

[ljcoomber]

Re: more elaboration... DynamoDB supports (fairly) rich query language which would be hard to abstract over. Targeting a spring-data alike abstraction though sounds very do-able.