It seems reasonable to compare these options based on several different properties: setup time (low is better), approach (serverless is better), involved resources (few is better), costs estimate (low is better) and new code possibly required (none is better).
Se si usano window functions (es. LAG) per calcolare delta tra timestamp Unix, il risultato "ignora" eventuali switch di ora legale/solare (correttamente, dato che un timestamp Unix conta esclusivamente il tempo che scorre).
Nell'utilizzo avanzato di AWS CDK, si realizza prima o poi l'esigenza di centralizzare alcune logiche e risorse in maniera da poterle riutilizzare in maniera rapida, riducendo il codice boilerplate.
Anche se una prima analisi potrebbe suggerire che la soluzione sia l'implementazione di una "casalinga" factory - pythonica sì, ma non conforme alle best practices di CDK - la risposta probabilmente più corretta potrebbe riguardare l'implementazione di un costrutto L3, descritto come:
designed to help you complete common tasks in AWS, often involving multiple kinds of resources.
Relational: data are stored in tabular form (rows and columns), where each row represents a unique record. Tables can be put in relation with each other through joins and queried via SQL;
Key-value: non-relational database where each record stored as a unique key with its associated value, resembling a dictionary-like structure;
Document: semi-structured and hierarchical databases for catalogs and content management systems, often stored as JSON;
Graph: the way the data are stored is graph-based, with nodes and edges connecting each data source with the others;
Time-series: database optimized for records which indices are timestamps.
Suppose you have a CodeBuild project triggered by a push on a given branch of a linked CodeCommit repo. If the build is particularly heavy, you might want to ensure its correctness before an actual commit to the related repo - for example, you might be interested in testing the build process specified in buildspec.yml locally.