Support Azure Functions Node.js V4 (New Programming Model)

[mildronize]

In Azure Functions Node.js v4: https://aka.ms/AzFuncNodeV4, they estimates public preview for March 2023 and general availability for July 2023.

Ref

• Azure Function Nodejs Roadmap 2023: https://github.com/Azure/azure-functions-nodejs-library/wiki/Roadmap
• Azure Function V4 demo https://github.com/ejizba/func-nodejs-prototype

Catch up Breaking Changes

• Expose a core api from the worker so that apps and npm packages can contribute programming model features (e.g. registering hooks & functions) #567
• Establish a new pattern of shipping the programming model in an npm package instead of directly in Azure. We plan to ship both the old and new programming models in this manner. #568
• Add entrypoint for app-level code #537
• Allow registering functions through code instead of "function.json" files #569
  • Add api for registering a function in code #619
• Implement new programming model based on prototype mentioned above #480

Discussion

• This is breaking change to remove function.json and a lot changes
• v4 support limited binding types Almost similar with Python v2 Models
• However, we still use app.generic helper function to register any supported triggers and bindings, as shown in example below:

  import { app, InvocationContext, trigger } from '@azure/functions'; // 4.0.0-alpha.8
  app.generic('myEventGrid',{
  trigger: trigger.generic({
    type: 'eventGrid'
  }),
  handler: async (request: unknown, context: InvocationContext) => {
    context.log('function name is ', context.functionName)
  }
  });

• All helper functions will call app.generic function:

  export function http(name: string, options: HttpFunctionOptions): void {
      options.return ||= output.http({});
      generic(name, {
          trigger: trigger.http({
              authLevel: options.authLevel,
              methods: options.methods,
              route: options.route,
          }),
          ...options,
      });
  }

• generic function will call Azure function runtime API directly via coreApi.registerFunction instead of using function.json provided in the root path, this allow us to create more fluent APIs around the v4 model.

  export function generic(name: string, options: FunctionOptions): void {  
    //...
    const coreApi = tryGetCoreApiLazy();
    if (!coreApi) {
        console.warn(
            `WARNING: Skipping call to register function "${name}" because the "@azure/functions" package is in test mode.`
        );
    } else {
        coreApi.registerFunction({ name, bindings }, <FunctionCallback>options.handler);
    }
  }

[mildronize]

Main branch for support v4 poc-func-v4

[mildronize]

After I've made successfully proof of concept for #82, I've pretty clear to setup direction of interface style next release for Azure Function Node.js V4.

Next Actions:

• [ ] All decorators proof of concept will be archived for future use (Backup branch)
• [ ] Make sure that only @nammatham/core is still remain and ready for publish NPM registry.

[mildronize]

For v2 release, will use functional approaches for provide type-safe APIs, you can see the full explanation in the #82, however, integrating with Dependency Injection Tools and container is quite usefully, for user migrating from v1, which is use inversify as backbone IoC tools,

In order to make sure v2 will works with Dependency Injection Tools and container will be PoC and implemented as external packages (In my PoC) for anyone can use, not strict to Nammatham library.

So, v2 is pass the process of proof concept, it's in alpha release https://github.com/thaitype/nammatham/releases/tag/v2.0.0-alpha.6 (For the latest release now), it's unnecessary to continue with this issue, the alpha release has work with Azure functions v4 model,