Proposal: Extending hooks about azure-functions-nodejs-worker HOT 11 CLOSED

Sure thing, I'll split them out as children of this one. I mostly started writing this as a collection of ideas for discussion and it's sort of expanded from that and now probably warrants being broken down for more concise discussions.

from azure-functions-nodejs-worker.

Added two more ideas after doing some more experiments with a more complex application

from azure-functions-nodejs-worker.

we could write hooks that are simplified across the different programming models.

Can you expand on this? Our plan was to discourage people from using hooks from the worker directly. We want to keep the worker as a backwards-compatible, barebones api and I think we'd put most of the features you're asking for in the library package. Azure/azure-functions-nodejs-library#7

from azure-functions-nodejs-worker.

The current folder-based approach for Functions isn't going to be going away, so there'll be a need to support writing something in that manner as well as something that leverages the library package.

Let's say you're building a library to work with MongoDB. You'd add a hook that establishes the connection before an invocation, but since it's a generic library you wouldn't want to tie it to any specific approach to writing Functions. So you need a generic way to provide the Mongo connection, but there isn't a way to do that at present.

from azure-functions-nodejs-worker.

The folder-based approach can still be used in conjunction with the library package (usage here). v4 is the priority for adding hooks, but I think we were still planning on adding them to v3 of the package.

To me, the open question is how much we want to support the scenario you mention where a generic library doesn't want to tie themselves to a specific major version of the library package. I'm open to ideas, but hesitant to add a bunch of stuff in the worker. We really want to keep this api barebones and punt all the fancy/nice logic to the library packages.

from azure-functions-nodejs-worker.

Would there be much need to change the hooks in the worker though? If we were to leverage hookData then it's already there, it's just passing that to the invocation channel rather, which is admittedly a change but it's then downstream of the channel to do something with that argument.

Otherwise if we made the types more obvious then it'd be apparent that the invocationContext could be used for it (which is the approach I've taken).

from azure-functions-nodejs-worker.

Would there be much need to change the hooks in the worker though?

I'm confused, because I thought all the above requests were for the worker. Perhaps this would be easier if we split this into separate issues. Here is how I would split it up and the repo I think each should be assigned to:

• Evolving the types - worker
• Adding more richness to HookContext (everything except hook filters) - library
• Hook filters - library (I think this one deserves its own discussion)
• Pass data from hooks to Functions - library
• Ability to cancel Function runs - worker

I'll give you first crack at splitting the issues up, but I'm happy to do it myself if that's easier for you.

from azure-functions-nodejs-worker.

Regarding the HookContext and filtering - is that something that would live in library or in the worker?

Is the "plumbing" needed for that is only in the library, won't we be restricting the feature to only work in that implementation and any other implementations that get created would have to replicate it? After all, the things you'd likely filter on (name of function, trigger type, additional input bindings, etc.) are common across all implementations of a library.

from azure-functions-nodejs-worker.

Filtering is already possible which is why I don't think we need to do anything in the worker. Things like the name of the function, trigger type, etc. are already available on the invocationContext and users can filter themselves with a simple if case. I acknowledge we could make filtering easier, but the design for that will be pretty subjective and thus I feel like that discussion belongs in the library.

At the end of the day, we want people directly referencing the library, so no they shouldn't have to replicate anything. We don't want people using the core api directly except in very rare cases.

from azure-functions-nodejs-worker.

Oh, I didn't realise that all that was available off the invocationContext - possibly with #665 can help address the discoverability of that.

from azure-functions-nodejs-worker.

Closing this since it's been split up into individual issues

from azure-functions-nodejs-worker.