search

Azure / azure-functions-nodejs-worker

The Node.js worker for the Azure Functions runtime - https://functions.azure.com
MIT License
107 stars 44 forks source link

[Hooks] Evolving the types #665

Closed aaronpowell closed 1 year ago

aaronpowell commented 1 year ago

Parent topic - https://github.com/Azure/azure-functions-nodejs-worker/issues/664

Looking at the types as defined here https://github.com/Azure/azure-functions-nodejs-worker/blob/f6d362519dfb35c608446757dbd6529c648a7fc9/types-core/index.d.ts#L52-L62

There isn't much in common with them, the type of hook to be registered are strings in the overload and the types for each callback don't have a common base type. As a result, trying to create a generic middleware function in the library project can be difficult without a lot of overloads there to ensure that the type system is happy.

Using an enum or union for the name of the hook would make it simpler to have other places within the code be aware of valid hook names.

For the callbacks, it'd be helpful if they inherited a base callback type as it can make for simpler type signatures elsewhere where you might want to create an abstraction layer over the hooks (again, something that could be exposed in the new programming model).

ejizba commented 1 year ago

Discussed this one a bit during today's sync. We don't want people using the "@azure/functions-core" api directly. It's clunky to use, it's slow for us to roll out changes, and we have to be super careful about backwards compatibility. There's quite a few hooks requests (more than we have time for) and we want to prioritize the work on the npm package. Closing this issue in favor of https://github.com/Azure/azure-functions-nodejs-library/issues/7

aaronpowell commented 1 year ago

I think that for any of the work in the library to be done, this will need to be tackled as the library package will need these types and at present they are inflexible and make creating abstractions difficult.

ejizba commented 1 year ago

Discussed a bit offline. Current plan is to implement all of this stuff in the library package, not the worker. I don't think it'll be too inflexible/difficult, but we can always revisit if @hossam-nasr finds otherwise when working on the prototype.

Also when I say "library" package I'm talking specifically about @azure/functions. Aaron brought up that there could be other libraries that want to reference @azure/functions-core instead of @azure/functions. We want to see what people think of the support in @azure/functions before we go down that road, though