|Branch||Status||Runtime Version||Support level||Node.js Versions|
|v2.x (default)||3||GA (Recommended)||14, 12, 10|
|v1.x||2||GA (Maintenance mode)||10, 8|
NOTE: The branch corresponds to the worker version, which is intentionally decoupled from the runtime version.
git clone https://github.com/Azure/azure-functions-nodejs-worker
npm run build
languageWorkers:node:workerDirectory = <path to azure-functions-nodejs-worker directory>
languageWorkers:node:workerDirectoryas an environment variable.
languageWorkers:node:arguments = --inspect-brk
languageWorkers:node:argumentsas an environment variable.
Make sure that
languageWorkers:node:arguments are set correctly. When you start your functions host, you should see your custom path to workerDirectory and any arguments you passed to the node. If it was not set correctly, your output may look like the default output:
Starting language worker process:node "%userprofile%\AppData\Roaming\npm\node_modules\azure-functions-core-tools\bin\workers\node\dist/src/nodejsWorker.js" --host 127.0.0.1 --port 5134 --workerId fd9b17c3-8ffb-49f7-a4e3-089a780e7a00 --requestId 14e27374-9395-42d4-a639-bd67e0e770a4 --grpcMaxMessageLength 134217728
Read more on local debugging in our docs.
package.ps1 creates the nuget package for the worker.
It builds and webpacks the generated node files into a bundle. We include several grpc native modules, for x86/x64 versions of windows, osx, linux
The nuget package can be deployed from the appveyor job at: https://ci.appveyor.com/project/appsvc/azure-functions-nodejs-worker
types/public/Interfaces.d.ts is a generated file from
src/public/Interfaces.ts. If you want to add a change to
Interfaces.d.ts, please make the change first to
Interfaces.ts and then
npm run build to generate the appropriate type definitions. Any additional type definition tests should go in
we use azure functions extensively for smaller /utility kind of functionalities, best part is functions are serverless so we are paying only when we use the resources, best for the applications where you don't want to allocate the dedicated/shared resource for rarely used applications we are saving lots with this approach. but we have to bare the little and ignorable cold start issues if we are choosing the serverless, if that is the matter we go for the app service plan.
we are working on serverless architecture using the azure functions since 6 months. the main reason we have chosen the Azure Functions because of its INPUT and OUTPUT Binders we have scenarios where we need this binder concept to flow the process seamlessly and configurable. these binders are very helpful if we want to decouple the system, some utilities we have executed rarely so we are saving some bucks using the consumption-based plan.