-
Notifications
You must be signed in to change notification settings - Fork 26
[WIP] Refactor to support Promises and Async/Await #9
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Patricio Diaz <[email protected]>
Signed-off-by: Patricio Diaz <[email protected]>
Thank you for this PR 👍 |
module.exports = (event, context) => { | ||
let err; | ||
// callback version | ||
const delayCallback = cb => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now part of the main template, was that intended or was it a mistake?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see handler.js as an example on how to build the code for the serverless function. As the main motivation for this refactoring is to handle asynchronicity, I use that function to simulate some load, and show how to take advantage of this new feature. But it's just a proposal, you can keep it or use the original example.
setTimeout(() => cb(delay), delay * 1000); | ||
} | ||
|
||
module.exports = (event, context, next) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The next
parameter is new I think? Why is it needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we use express we are using a framework, which is in control of the execution of our code, not us.
Having said that, the middleware
function at index.js
is in the "middle" of the execution flow, so we need to "fit" in that schema, node.js coders are used to and aware of that.
I think it's better if we just "build" the response in handler.js
and let middleware
in index.js
take care of sending the response and handling errors.
Then once you build the response you call next
to return control to the framework.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The next
parameter is supposed to be used when you return a callback to the middleware, it's not used when returning a Promise (Promise or Async/Await)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't line the next() parameter, it's confusing. mixes express and faas programming.
With that said, I believe callbacks should removed altogether, so it doesn't become an issue anymore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know the use of the next() function it is confusing, but is something a express user is used to. I'm open to suggestions on how to solve the callback call in a different way. I already suggested that we need to drop support for it, but until that happens there must be a way to use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The other way is to pass the res object to the handler function, with passes the control of the flow to it. I think the function main code has to be in control of that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or not use callbacks ;-)
I rebuilt a brand new template - thanks for your inspiration. will publish soon - I am testing right now. It also works differently, more inlined with lambda.
- New better intuitive handler.js
- Super tiny docker image using multistage build, down to 65MB (from 118MB!)
- Garbage collector manually triggered every 30s
- Image properly handles signals using a graceful shutdown
- Catch all uncaught exceptions and unhandled promise rejections
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, that's something I already asked about, what happens if we don't use callbacks at all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused about how the handler.js template changed.
As a personal comment, I think we can start thinking on dropping support for Callbacks and just support Promises, I think nobody would complain nowadays. |
generally speaking I don't like the way openfaas handles the context. context and results should be two different structures. |
Signed-off-by: Patricio Diaz [email protected]
This refactor is intended to give the node10-express template the ability to respond to promise or async/await based handler functions.
The handler in this PR has 3 examples for each scenario: callback, promise, async/await.
This proposal moves the control of sending the response to the
middleware
function inindex.js
.When using the Promise and Async/Await flavors of handler, you must return the
context
variable with the resulting value you want to return.If you are using the Callback flavor of handler, you must use the
next
function which is passed as the third parameter tohandler
to pass the control tomiddleware
How it was tested
For a Callback version of handler.js
handler.js
For a Promise version of handler.js
handler.js
For a Async/Await version of handler.js
handler.js