feat(idempotency): create initial class structure for function idempotency

[jeffrey-baker-vg]

Description of your changes

How to verify this change

Related issues, RFCs

Issue number:

PR status

Is this ready for review?: NO
Is it a breaking change?: NO

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding changes to the examples
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published in downstream module
• The PR title follows the conventional commit semantics

Breaking change checklist

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[ijemmy]

For reviewers (@dreamorosi @flochaz), here's a class diagram in Mermaid:

Note that the scope of this design is only for FR2 (making a wrapper function for idempotency at function level)

classDiagram
  class IdempotencyRecord {
    -status: string
    +expiryTimestamp: number
    +inProgressExpiryTimestamp: number
    +responseData: string
    +payloadHash: string
    +getStatus() string
    +isExpired() boolean
    +responseJsonAsObject() Record<string, unknown>
  }
  class PersistenceLayerInterface{
     <<interface>>
     +configure(functionName: string)
     +saveInProgress() void
     +saveSuccess() void
     +deleteRecord() void
     +getRecord() Idempotency
  }
  class PersistenceLayer {
    +constructor()
    +configure(functionName: string)
    +deleteRecord() void
    +getRecord() IdempotencyRecord
    +saveInProgress() void
    +saveSuccess() void
    #_deleteRecord()* void
    #_getRecord()* IdempotencyRecord
    #_putRecord(record: IdempotencyRecord)* void
    #_updateRecord()* void
  }
  class DynamoDBPersistenceLayer {
    #_deleteRecord()* void
    #_getRecord()* IdempotencyRecord
    #_putRecord(record: IdempotencyRecord)* void
    #_updateRecord()* void
  }

  class makeFunctionIdempotent{
    <<topLevelMethod>>
  }
  
  class IdempotencyOptions{
    <<type>>
  }

  PersistenceLayerInterface <|-- PersistenceLayer
  PersistenceLayer <|-- DynamoDBPersistenceLayer

  IdempotencyRecord <..PersistenceLayer
  IdempotencyRecord <..DynamoDBPersistenceLayer

  PersistenceLayer<..IdempotencyOptions
  IdempotencyOptions<..makeFunctionIdempotent
  

Loading

[ijemmy]

I have a few changes requested and asked some questions.

[ijemmy]

Apart from @aws-lambda-powertools/commons, @types/aws-lambdaandlodash`, let's remove the other libraries we are not sure if we will be using yet.

[ijemmy]

To maintainers ( @flochaz @dreamorosi)
I know that this is all packages have the same copy. But this duplicates the top-level README.md and confuses readers that there is a new information here that is different from the top-level one.

I propose having just a link to our documentation page for now. Then we can use this README.md for any dev related items like design, class diagram, etc. The usages should always be the doc. Do you agree?

[dreamorosi]

Hi,

Until we publish the package we can use the README like you suggest since it won't be published anywhere. It's good to have design, class diagrams, etc. near the code & version controlled.

Once we start publishing the package on NPM however I would be inclined to follow the same structure we have for all the others since it's the "landing page" of the package on NPM and customers might arrive to that page without having seen our repo or our docs.

[ijemmy]

Suggested change

	"description": "TBD",
	"description": "The idempotency package for the AWS Lambda Powertools for TypeScript library. It provides options to make your Lambda functions idempotent and safe to retry.",

[ijemmy]

(Note for reviewers): The term "Options" is consistent with other utilities (logger, metrics, tracer).

However, Python's idempotency uses the term "Config" instead (code). Still, I prefer "Options" as used here. It's more consistent. Let me know if you disagree.

[ijemmy]

Shall we use an enum here instead?

Python uses these values. We should keep them consistent.

INPROGRESS
COMPLETED
EXPIRED

[ijemmy]

Suggested change

	public responseData: string = '',
	public responseData: string | undefined,

Let's use undefined to explicitly say that we don't have responseData yet.

I doubt if any good API will return an empty string. But it could happen.

[ijemmy]

(No action needed, just to start discussion)

I wonder if we should return result as enum or throw exception in edge cases.

Python is using (internal) exception. I assume that is the case for this interface.

I don't have a strong opinion on this as it's internal and not exposed to users.

[ijemmy]

Should we have this class in a separated file?

[ijemmy]

@jeffrey-baker-vg Also, please update the PR description and check any box that's relevant.

[flochaz]

LGTM