Make “transforms” more flexible by allowing async behavior

[andrewbranch]

I’d like to use the beforeSave function not so much as a transformation, but as a place to do some asynchronous work, and have the ability to carry out or cancel the save based on the results of the async task.

For example, the specific case I have right now is a resource that represents a file in an S3 bucket: I want to perform an upload to S3, which upon succeeding, will continue to save to Mongo. If the bucket upload fails, though, I want to be able to reject or something and kick off an error response.

A related thought that I’ve been thinking for some time is that maybe it would be worth exploring making each of these steps a distinct middleware. Although, that would be a function signature specific to Connect and Express servers, so maybe that doesn’t jive with the project’s vision. At any rate, I think these transforms could detect whether a Promise is being returned, and wait for it to settle if needed.

What do you think, @ethanresnick?

[ethanresnick]

Hey Andrew,

At any rate, I think these transforms could detect whether a Promise is being returned, and wait for it to settle if needed.

I 100% agree with this and would welcome a PR.

A related thought that I’ve been thinking for some time is that maybe it would be worth exploring making each of these steps a distinct middleware. Although, that would be a function signature specific to Connect and Express servers, so maybe that doesn’t jive with the project’s vision.

There's definitely a way to do this without binding us to connect's signature, but I'm not sure I understand the value. I guess it would let the user skip the remaining transforms and respond with a success message earlier. Is there a use case for that? (Note: the user can already skip the remaining steps and jump straight to responding by throwing an error in a transform—or, when we implement your suggestion above, by returning a promise that gets rejected.)

[andrewbranch]

I guess it would let the user skip the remaining transforms and respond with a success message earlier.

Yeah, and moreover, it would remove the need for named hooks like beforeSave altogether, because the implementer could insert steps at any position in the chain and decide whether to call next or to send a response. (Either of which can be done in an async callback—only reason it came to mind.) But this is much more hand-waving than is currently necessary to land this feature.

Can you give some guidance on where to add tests for this? Maybe in the create-resource integration tests?