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
I have separate systems that create and manage hard resources like dynamodb tables, and that use those resources. Normally, I export those variables using different methods, but I wanted to start making my system more robust in the event of changes, including hot switching of tables. To to that, I would have to be able to resolve the name of the table in runtime.
To achieve that, I am exporting SSM parameters with the required names, but I cannot resolve it in runtime, as TableNameResolver does not support an asynchronous function to be set. As aws-sdk is mostly asynchrounous, it makes it quite hard to determine names by accessing external resources. It is achievable, but depends on complex synchronisation code that becomes an overkill.
Therefore, it would be nice if TableNameResolver could support Promise<string> as return value as well, allowing a large range of resolutions to happen.
The text was updated successfully, but these errors were encountered:
To support an async TableNameResolver function a lot of refactoring would be necessary.
But: since the TableNameResolver is called every time a new Request instance is created (eg. myStore.get(..) --> new GetRequest()) you could simply await your own promise where you call updateDynamoEasyConfig(..) in the end with your new TableNameResolver function. Afterwards all requests would use the new function.
Only the DynamoStore actually stores the table name generated from TableNameResolver . But this property (myStore.tableName) is never used from dynamo-easy itself (We could simply replace it with a getter calling the TableNameResolver every time to be more consistent).
Yeah, your method works, but would force to do the resolution of all table names, for all models, at once.
My goal would be something like what you mention in your last paragraph; resolving it every you need to use it. That would give the developer full freedom to decide whether to cache to value, to resolve every time, and to only resolve what is absolutely needed, no extra calls involved.
I understand the changes my be slightly large, but I thought it could be a good idea, so I am throwing it out there! =)
Thanks for taking some time to consider it, and feel free to close it if it is too much.
I have separate systems that create and manage hard resources like dynamodb tables, and that use those resources. Normally, I export those variables using different methods, but I wanted to start making my system more robust in the event of changes, including hot switching of tables. To to that, I would have to be able to resolve the name of the table in runtime.
To achieve that, I am exporting SSM parameters with the required names, but I cannot resolve it in runtime, as
TableNameResolver
does not support an asynchronous function to be set. Asaws-sdk
is mostly asynchrounous, it makes it quite hard to determine names by accessing external resources. It is achievable, but depends on complex synchronisation code that becomes an overkill.Therefore, it would be nice if
TableNameResolver
could supportPromise<string>
as return value as well, allowing a large range of resolutions to happen.The text was updated successfully, but these errors were encountered: