|
|
|
|
|
by komon
1669 days ago
|
|
DynamoDB is an interesting beast. It's hard for me to recommend it for most use cases anyway. It was designed to power experiences that look like shopping carts: relatively short-lived, mostly append-only, needing a flattish performance curve as the number of items and users go up, with a really natural partition key. Using it as the primary storage of your app means you play the part of query planner a lot of the time. If your data is especially graph-structured you might end up doing so-called "single table design" where all objects end up in the same table that has its keys constructed carefully (compound keys formed by string concatting), And has secondary sparse indices to power other access patterns. And definitely plan on overfetching as an _optimization_ to prevent many small queries to dynamo, especially in a GraphQL context where we have no idea what fields are being requested at fetch time. |
|