search

aws-amplify / amplify-js

A declarative JavaScript library for application development using cloud services.
https://docs.amplify.aws/lib/q/platform/js
Apache License 2.0
9.42k stars 2.13k forks source link

Cross-service transaction #2111

Closed YikSanChan closed 5 years ago

YikSanChan commented 5 years ago

Is your feature request related to a problem? Please describe. I have an app, in which I want to upload an image as part of a form and submit the form to create an item. Since AWS amplify stores files via Storage service first and then it saves the created item (via GraphQL backend in my case) into DynamoDB, if the first step succeeds and the second step fails, it is not ideal.

Describe the solution you'd like Cross-service transactions between storage, database, etc.

Describe alternatives you've considered The problem is hard to solve in client code I believe.

elorzafe commented 5 years ago

@YikSanChan thanks for your feedback. I labeled this as a feature-request

baffleinc commented 5 years ago

Is this a validation issue? I would try to upload the file first then if successful, validate the form and push to graphql. S3 succeeding/failing is essentially your server side validation.

If you wanted to track the file against the particular user you could use versioning to create a progressive version of the entry.

Finally it can help to create an S3Object type in your scema to link the form object and file.

YikSanChan commented 5 years ago

Is this a validation issue? I would try to upload the file first then if successful, validate the form and push to graphql. S3 succeeding/failing is essentially your server side validation.

If you wanted to track the file against the particular user you could use versioning to create a progressive version of the entry.

Finally it can help to create an S3Object type in your scema to link the form object and file.

Thanks for the reply! No necessarily a validation rule, I simply want to make sure the following case doesn't appear: After hitting the "submit form" button, the file is uploaded to storage service, then when I try to write the whole form to dynamodb it fails. As a result, I have an orphan file in the storage.

Yes, these are all the things I can do in client side, just like NoSQL users can always hack around to guarantee some level of transaction support. But this doesn't change the fact that Google Spanner / TiDB provides a more user-friendly solution to developers.

mbahar commented 5 years ago

@YikSanChan did you evaluate AppSync pipeline resolvers? https://docs.aws.amazon.com/appsync/latest/devguide/pipeline-resolvers.html Seems like it is and applicable use-case.

YikSanChan commented 5 years ago

@mbahar Is it atomic?

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

sammartinez commented 5 years ago

@YikSanChan Is this still a valid use case, I do want to point out that we do have documentation on the Storage category and also React Components in regards to this. Please let us know if you are still looking for this.

github-actions[bot] commented 3 years ago

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels or Discussions for those types of questions.