You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would the team be interested in the contribution of a DynamoDB Lock Client for TypeScript?
If I wrote this could we work on absorbing it into an official package?
Context
I worked on and helped build the DynamoDB Lock Client, working with Sasha Slutsker and David Yanacek, while I was employed at Amazon as a former Principal Engineer (2007-2021) [1], and I'm currently at a company that use TypeScript, finding myself desiring this library's capabilities.
I believe I'm acquainted with its design and design decisions after the passage of time sufficiently that I could build a TypeScript port with identical or nearly identical semantics, potentially even compatible with the existing library (though that wouldn't be a primary goal – given that it's rare in well-designed systems, IMO) for multiple apps to access a data store).
Proposal
I'd probably propose creating a separate package for the TypeScript variant: would amazon-dynamodb-lock-client-ts work? This would facilitate keep their source histories different (an advantage if we're making no major architectural or compatibility changes, which seems unlikely) and also publishing keep the TS package minimal so as to publish to NPM.
Interoperability: Nice to have
Ideally the two libraries would be able to interoperate with locking data in the same table, but that's a nice-to-have not a hard requirement in my opinion, since I don't have a use-case for two different programs interacting using locks with the same DDB table. That would be risking subtle bugs and problems.
Additionally, as general design principle I strive to have only a single program or service interact with each data store, like DynamoDB table, so I don't expect to come across a use case where both TS and Java programs are locking the same table.
So I'd aim for compatibility in naming and structure, but (depending on time available) not necessarily test or prove that they can actually interoperate; instead they'll just leave recognizable patterns in the table items, and use similar techniques for locking, heartbeating, and updates.
[1] My name is not in the package's commit history or developer list because it began as an internal package, and we basically started over for the public OSS version, after having made that decision; and I was not involved in the OSS work.
The text was updated successfully, but these errors were encountered:
Would the team be interested in the contribution of a DynamoDB Lock Client for TypeScript?
If I wrote this could we work on absorbing it into an official package?
Context
I worked on and helped build the DynamoDB Lock Client, working with Sasha Slutsker and David Yanacek, while I was employed at Amazon as a former Principal Engineer (2007-2021) [1], and I'm currently at a company that use TypeScript, finding myself desiring this library's capabilities.
I believe I'm acquainted with its design and design decisions after the passage of time sufficiently that I could build a TypeScript port with identical or nearly identical semantics, potentially even compatible with the existing library (though that wouldn't be a primary goal – given that it's rare in well-designed systems, IMO) for multiple apps to access a data store).
Proposal
I'd probably propose creating a separate package for the TypeScript variant: would
amazon-dynamodb-lock-client-ts
work? This would facilitate keep their source histories different (an advantage if we're making no major architectural or compatibility changes, which seems unlikely) and also publishing keep the TS package minimal so as to publish to NPM.Interoperability: Nice to have
Ideally the two libraries would be able to interoperate with locking data in the same table, but that's a nice-to-have not a hard requirement in my opinion, since I don't have a use-case for two different programs interacting using locks with the same DDB table. That would be risking subtle bugs and problems.
Additionally, as general design principle I strive to have only a single program or service interact with each data store, like DynamoDB table, so I don't expect to come across a use case where both TS and Java programs are locking the same table.
So I'd aim for compatibility in naming and structure, but (depending on time available) not necessarily test or prove that they can actually interoperate; instead they'll just leave recognizable patterns in the table items, and use similar techniques for locking, heartbeating, and updates.
[1] My name is not in the package's commit history or developer list because it began as an internal package, and we basically started over for the public OSS version, after having made that decision; and I was not involved in the OSS work.
The text was updated successfully, but these errors were encountered: