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
Here are some thoughts I had, which you may have already considered.
entry point
Could the entry point be configurable? Some folks may want it in a specific folder and in a specific file. Could we have the app follow a convention such as this?
use the package.json main file , if set
use the convention src/app.js if no main file exists
The goal is to allow for customization, but have a practical default. The main file is a conventional and familiar option. if this is not possible, perhaps the host.json
onTrigger
The app.onTrigger implies there are other things we can connect using app.on*. Could the trigger part be an argument? Could Trigger, which is arguably the most common type, be the conventional default? Then the code would look like this:
app.on(new HttpTrigger('api/bye', ['GET'], goodbyeFunction)
//or
app.on('trigger', new HttpTrigger('api/bye', ['GET'], goodbyeFunction)
We can't use the types to determine this because it has to support javascript. But perhaps if trigger is the 75% case, we should make it the default.
array or strings
Consider allowing a string or array for the methods.
app.on(new HttpTrigger('api/bye', ['GET'], goodbyeFunction)
// or
app.on(new HttpTrigger('api/bye', 'GET', goodbyeFunction)
consider method as a method? (pun intended)
Not that this now implies that this is a http trigger and the get is used instead of the on. This would mean you cant hook up multiple methods at one time ... but do most APIs allow multiples? Curious if folks do this or not.
With node, this startup process ends usually when the server starts to listen. With this app it is implied. This is also where a lot of people console log startup messages which may include the port number, ssl usage, and sometimes all active endpoints. Would it be helpful to provide a app.listen().then( ... ) to both make it easier for people to know when it starts and where to put such messages?
port
Often the port is set in this code for Express and other servers. Could we allow port setting in this startup routine?
error handling
It would be helpful to see how errors are handled given the unique error handling process in Node middleware.
The text was updated successfully, but these errors were encountered:
Love this , sooooo much!
Here are some thoughts I had, which you may have already considered.
entry point
Could the entry point be configurable? Some folks may want it in a specific folder and in a specific file. Could we have the app follow a convention such as this?
package.json
main file , if setsrc/app.js
if no main file existsThe goal is to allow for customization, but have a practical default. The main file is a conventional and familiar option. if this is not possible, perhaps the
host.json
onTrigger
The
app.onTrigger
implies there are other things we can connect usingapp.on*
. Could the trigger part be an argument? Could Trigger, which is arguably the most common type, be the conventional default? Then the code would look like this:We can't use the types to determine this because it has to support javascript. But perhaps if trigger is the 75% case, we should make it the default.
array or strings
Consider allowing a string or array for the methods.
consider method as a method? (pun intended)
Not that this now implies that this is a http trigger and the
get
is used instead of theon
. This would mean you cant hook up multiple methods at one time ... but do most APIs allow multiples? Curious if folks do this or not.who is listening
With node, this startup process ends usually when the server starts to listen. With this app it is implied. This is also where a lot of people console log startup messages which may include the port number, ssl usage, and sometimes all active endpoints. Would it be helpful to provide a
app.listen().then( ... )
to both make it easier for people to know when it starts and where to put such messages?port
Often the port is set in this code for Express and other servers. Could we allow port setting in this startup routine?
error handling
It would be helpful to see how errors are handled given the unique error handling process in Node middleware.
The text was updated successfully, but these errors were encountered: