Important

The content of this article changes based on your choice of the Node.js programming model in the selector at the top of this page. The version you choose should match the version of the@azure/functions npm package you're using in your app. If you don't have that package listed in yourpackage.json, the default is v3. Learn more about the differences between v3 and v4 in themigration guide.

The v3 model registers a function based on the existence of two files. First, you need afunction.json file located in a folder one level down from the root of your app. Second, you need a JavaScript file thatexports your function. By default, the model looks for anindex.js file in the same folder as yourfunction.json. If you're using TypeScript, you must use thescriptFile property infunction.json to point to the compiled JavaScript file. To customize the file location or export name of your function, seeconfiguring your function's entry point.

The function you export should always be declared as anasync function in the v3 model. You can export a synchronous function, but then you must callcontext.done() to signal that your function is completed, which is deprecated and not recommended.

Your function is passed aninvocationcontext as the first argument and yourinputs as the remaining arguments.

The following example is a simple function that logs that it was triggered and responds withHello, world!:

{  "bindings": [    {      "type": "httpTrigger",      "direction": "in",      "name": "req",      "authLevel": "anonymous",      "methods": ["get", "post"]    },    {      "type": "http",      "direction": "out",      "name": "res"    }  ]}

module.exports = async function (context, request) {  context.log("Http function was triggered.");  context.res = { body: "Hello, world!" };};

{  "bindings": [    {      "type": "httpTrigger",      "direction": "in",      "name": "req",      "authLevel": "anonymous",      "methods": ["get", "post"]    },    {      "type": "http",      "direction": "out",      "name": "res"    }  ],  "scriptFile": "../dist/HttpTrigger1/index.js"}

import { AzureFunction, Context, HttpRequest } from "@azure/functions";const httpTrigger: AzureFunction = async function (  context: Context,  request: HttpRequest): Promise<void> {  context.log("Http function was triggered.");  context.res = { body: "Hello, world!" };};export default httpTrigger;

The programming model loads your functions based on themain field in yourpackage.json. You can set themain field to a single file or multiple files by using aglob pattern. The following table shows example values for themain field:

In order to register a function, you must import theapp object from the@azure/functions npm module and call the method specific to your trigger type. The first argument when registering a function is the function name. The second argument is anoptions object specifying configuration for your trigger, your handler, and any other inputs or outputs. In some cases where trigger configuration isn't necessary, you can pass the handler directly as the second argument instead of anoptions object.

Registering a function can be done from any file in your project, as long as that file is loaded (directly or indirectly) based on themain field in yourpackage.json file. The function should be registered at a global scope because you can't register functions once executions start.

The following example is a simple function that logs that it was triggered and responds withHello, world!:

const { app } = require("@azure/functions");app.http("helloWorld1", {  methods: ["POST", "GET"],  handler: async (request, context) => {    context.log("Http function was triggered.");    return { body: "Hello, world!" };  },});

import {  app,  HttpRequest,  HttpResponseInit,  InvocationContext,} from "@azure/functions";async function helloWorld1(  request: HttpRequest,  context: InvocationContext): Promise<HttpResponseInit> {  context.log("Http function was triggered.");  return { body: "Hello, world!" };}app.http("helloWorld1", {  methods: ["GET", "POST"],  handler: helloWorld1,});

Your function is required to have exactly one primary input called the trigger. It might also have secondary inputs and/or outputs. Inputs and outputs are configured in yourfunction.json files and are also referred to asbindings.

Inputs

Inputs are bindings withdirection set toin. The main difference between a trigger and a secondary input is that thetype for a trigger ends inTrigger, for example typeblobTrigger vs typeblob. Most functions only use a trigger, and not many secondary input types are supported.

Inputs can be accessed in several ways:

• [Recommended] As arguments passed to your function: Use the arguments in the same order that they're defined infunction.json. Thename property defined infunction.json doesn't need to match the name of your argument, although we recommend it for the sake of organization.

  • JavaScript
  • TypeScript

  module.exports = async function (context, myTrigger, myInput, myOtherInput) { ... };

• As properties ofcontext.bindings: Use the key matching thename property defined infunction.json.

  • JavaScript
  • TypeScript

  module.exports = async function (context) {  context.log("This is myTrigger: " + context.bindings.myTrigger);  context.log("This is myInput: " + context.bindings.myInput);  context.log("This is myOtherInput: " + context.bindings.myOtherInput);};

Outputs

Outputs are bindings withdirection set toout and can be set in several ways:

• [Recommended for single output] Return the value directly: If you're using an async function, you can return the value directly. You must change thename property of the output binding to$return infunction.json like in the following example:

  {  "name": "$return",  "type": "http",  "direction": "out"}

  • JavaScript
  • TypeScript

  module.exports = async function (context, request) {  return {    body: "Hello, world!",  };};

• [Recommended for multiple outputs] Return an object containing all outputs: If you're using an async function, you can return an object with a property matching the name of each binding in yourfunction.json. The following example uses output bindings named "httpResponse" and "queueOutput":

  {    "name": "httpResponse",    "type": "http",    "direction": "out"},{    "name": "queueOutput",    "type": "queue",    "direction": "out",    "queueName": "helloworldqueue",    "connection": "storage_APPSETTING"}

  • JavaScript
  • TypeScript

  module.exports = async function (context, request) {  let message = "Hello, world!";  return {    httpResponse: {      body: message,    },    queueOutput: message,  };};

• Set values oncontext.bindings: If you're not using an async function or you don't want to use the previous options, you can set values directly oncontext.bindings, where the key matches the name of the binding. The following example uses output bindings named "httpResponse" and "queueOutput":

  {    "name": "httpResponse",    "type": "http",    "direction": "out"},{    "name": "queueOutput",    "type": "queue",    "direction": "out",    "queueName": "helloworldqueue",    "connection": "storage_APPSETTING"}

  • JavaScript
  • TypeScript

  module.exports = async function (context, request) {  let message = "Hello, world!";  context.bindings.httpResponse = {    body: message,  };  context.bindings.queueOutput = message;};

Bindings data type

You can use thedataType property on an input binding to change the type of your input. However, the approach has some limitations:

• In Node.js, onlystring andbinary are supported (stream isn't)
• For HTTP inputs, thedataType property is ignored. Instead, use properties on therequest object to get the body in your desired format. For more information, seeHTTP request.

In the following example of astorage queue trigger, the default type ofmyQueueItem is astring, but if you setdataType tobinary, the type changes to a Node.jsBuffer.

{  "name": "myQueueItem",  "type": "queueTrigger",  "direction": "in",  "queueName": "helloworldqueue",  "connection": "storage_APPSETTING",  "dataType": "binary"}

const { Buffer } = require("node:buffer");module.exports = async function (context, myQueueItem) {  if (typeof myQueueItem === "string") {    context.log("myQueueItem is a string");  } else if (Buffer.isBuffer(myQueueItem)) {    context.log("myQueueItem is a buffer");  }};

import { AzureFunction, Context } from "@azure/functions";import { Buffer } from "node:buffer";const queueTrigger1: AzureFunction = async function (  context: Context,  myQueueItem: string | Buffer): Promise<void> {  if (typeof myQueueItem === "string") {    context.log("myQueueItem is a string");  } else if (Buffer.isBuffer(myQueueItem)) {    context.log("myQueueItem is a buffer");  }};export default queueTrigger1;

Your function is required to have exactly one primary input called the trigger. It might also have secondary inputs, a primary output called the return output, and/or secondary outputs. Inputs and outputs are also referred to asbindings outside the context of the Node.js programming model. Before v4 of the model, these bindings were configured infunction.json files.

Trigger input

The trigger is the only required input or output. For most trigger types, you register a function by using a method on theapp object named after the trigger type. You can specify configuration specific to the trigger directly on theoptions argument. For example, an HTTP trigger allows you to specify a route. During execution, the value corresponding to this trigger is passed in as the first argument to your handler.

const { app } = require('@azure/functions');app.http('helloWorld1', {    route: 'hello/world',    handler: async (request, context) => {        ...    }});

import { app, HttpRequest, HttpResponseInit, InvocationContext } from "@azure/functions";async function helloWorld1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {    ...};app.http('helloWorld1', {    route: 'hello/world',    handler: helloWorld1});

Return output

The return output is optional, and in some cases configured by default. For example, an HTTP trigger registered withapp.http is configured to return an HTTP response output automatically. For most output types, you specify the return configuration on theoptions argument with the help of theoutput object exported from the@azure/functions module. During execution, you set this output by returning it from your handler.

The following example uses atimer trigger and astorage queue output:

const { app, output } = require('@azure/functions');app.timer('timerTrigger1', {    schedule: '0 */5 * * * *',    return: output.storageQueue({        connection: 'storage_APPSETTING',        ...    }),    handler: (myTimer, context) => {        return { hello: 'world' }    }});

import { app, InvocationContext, Timer, output } from "@azure/functions";async function timerTrigger1(myTimer: Timer, context: InvocationContext): Promise<any> {    return { hello: 'world' }}app.timer('timerTrigger1', {    schedule: '0 */5 * * * *',    return: output.storageQueue({        connection: 'storage_APPSETTING',        ...    }),    handler: timerTrigger1});

Extra inputs and outputs

In addition to the trigger and return, you might specify extra inputs or outputs on theoptions argument when registering a function. Theinput andoutput objects exported from the@azure/functions module provide type-specific methods to help construct the configuration. During execution, you get or set the values withcontext.extraInputs.get orcontext.extraOutputs.set, passing in the original configuration object as the first argument.

The following example is a function triggered by astorage queue, with an extrastorage blob input that is copied to an extrastorage blob output. The queue message should be the name of a file and replaces{queueTrigger} as the blob name to be copied, with the help of abinding expression.

const { app, input, output } = require("@azure/functions");const blobInput = input.storageBlob({  connection: "storage_APPSETTING",  path: "helloworld/{queueTrigger}",});const blobOutput = output.storageBlob({  connection: "storage_APPSETTING",  path: "helloworld/{queueTrigger}-copy",});app.storageQueue("copyBlob1", {  queueName: "copyblobqueue",  connection: "storage_APPSETTING",  extraInputs: [blobInput],  extraOutputs: [blobOutput],  handler: (queueItem, context) => {    const blobInputValue = context.extraInputs.get(blobInput);    context.extraOutputs.set(blobOutput, blobInputValue);  },});

import { app, InvocationContext, input, output } from "@azure/functions";const blobInput = input.storageBlob({  connection: "storage_APPSETTING",  path: "helloworld/{queueTrigger}",});const blobOutput = output.storageBlob({  connection: "storage_APPSETTING",  path: "helloworld/{queueTrigger}-copy",});async function copyBlob1(  queueItem: unknown,  context: InvocationContext): Promise<void> {  const blobInputValue = context.extraInputs.get(blobInput);  context.extraOutputs.set(blobOutput, blobInputValue);}app.storageQueue("copyBlob1", {  queueName: "copyblobqueue",  connection: "storage_APPSETTING",  extraInputs: [blobInput],  extraOutputs: [blobOutput],  handler: copyBlob1,});

Generic inputs and outputs

Theapp,trigger,input, andoutput objects exported by the@azure/functions module provide type-specific methods for most types. For all the types that aren't supported, ageneric method is provided to allow you to manually specify the configuration. Thegeneric method can also be used if you want to change the default settings provided by a type-specific method.

The following example is a simple HTTP triggered function using generic methods instead of type-specific methods.

const { app, output, trigger } = require("@azure/functions");app.generic("helloWorld1", {  trigger: trigger.generic({    type: "httpTrigger",    methods: ["GET", "POST"],  }),  return: output.generic({    type: "http",  }),  handler: async (request, context) => {    context.log(`Http function processed request for url "${request.url}"`);    return { body: `Hello, world!` };  },});

import {  app,  InvocationContext,  HttpRequest,  HttpResponseInit,  output,  trigger,} from "@azure/functions";async function helloWorld1(  request: HttpRequest,  context: InvocationContext): Promise<HttpResponseInit> {  context.log(`Http function processed request for url "${request.url}"`);  return { body: `Hello, world!` };}app.generic("helloWorld1", {  trigger: trigger.generic({    type: "httpTrigger",    methods: ["GET", "POST"],  }),  return: output.generic({    type: "http",  }),  handler: helloWorld1,});

Azure Storage Blob SDK Bindings Guide

The new SDK bindings capability in Azure Functions allows you to work directly with the Azure SDK types likeBlobClient andContainerClient instead of raw data. This provides full access to all SDK methods when working with blobs.

Step-by-Step Implementation Guide

1. Set up your project dependencies: Add the@azure/functions-extensions-blob extension preview packages to thepackage.json file in the project, which should include at least these packages:

{  "dependencies": {    "@azure/functions": "4.7.1-preview",    "@azure/functions-extensions-blob": "0.1.0-preview"  }}

2. Configure your application entry point: Add function app imports toindex.ts

import { app } from "@azure/functions";app.setup({  enableHttpStream: true,});

BlobClient Example

This example shows how to get the BlobClient from both a Storage Blob trigger and from the input binding on an HTTP trigger:

import "@azure/functions-extensions-blob"; // NOTE: Ensure this line is at the top of your functions file.import { StorageBlobClient } from "@azure/functions-extensions-blob";import { app, InvocationContext } from "@azure/functions";export async function storageBlobTrigger(  blobStorageClient: StorageBlobClient, // SDK binding provides this client  context: InvocationContext): Promise<void> {  context.log(`Blob trigger processing: ${context.triggerMetadata.name}`);  // Access to full SDK capabilities  const blobProperties = await blobStorageClient.blobClient.getProperties();  context.log(`Blob size: ${blobProperties.contentLength}`);  // Download blob content  const downloadResponse = await blobStorageClient.blobClient.download();  context.log(`Content: ${downloadResponse}`);}// Register the functionapp.storageBlob("storageBlobTrigger", {  path: "snippets/{name}",  connection: "AzureWebJobsStorage",  sdkBinding: true, // Enable SDK binding  handler: storageBlobTrigger,});

EnsureAzureWebJobsStorage connection string is defined inlocal.setting.json while testing locally. For testing local emulator use followinglocal.settings.json

{  "IsEncrypted": false,  "Values": {    "AzureWebJobsStorage": "UseDevelopmentStorage=true",    "FUNCTIONS_WORKER_RUNTIME": "node"  }}

ContainerClient Example with Input BindingFollowing example shows how to get theContainerClient from both a Storage Blob input binding using an HTTP trigger:

import "@azure/functions-extensions-blob"; // NOTE: Ensure this line is at the top of your functions file.import { StorageBlobClient } from "@azure/functions-extensions-blob";import { app, InvocationContext } from "@azure/functions";const blobInput = input.storageBlob({  path: "snippets",  connection: "AzureWebJobsStorage",  sdkBinding: true, // Enable SDK binding});export async function listBlobs(  request: HttpRequest,  context: InvocationContext): Promise<HttpResponseInit> {  // Get input binding for a specific container  const storageBlobClient = context.extraInputs.get(    blobInput  ) as StorageBlobClient;  // List all blobs in the container  const blobs = [];  for await (const blob of storageBlobClient.containerClient.listBlobsFlat()) {    blobs.push(blob.name);  }  return { jsonBody: { blobs } };}app.http("listBlobs", {  methods: ["GET"],  authLevel: "function",  extraInputs: [blobInput],  handler: listBlobs,});

Best Practices

1. Always import@azure/functions-extensions-blob first in your files to ensure side effects run
2. Set sdkBinding: true in your binding configuration
3. Use the appropriate client type for your operation:

• blobClient for operations on a single blob
• containerClient for operations on a container

4. Handle errors appropriately with try/catch blocks
5. For large blob operations, consider using streaming methods to avoid memory issues

Next Steps

Check out theBlob Storage SDK Bindings for Node.js Samplesfor more examples on how to incorporate SDK Bindings for Blob into your function app.

• BlobClient
• ContainerClient
• Readable Stream

Each invocation of your function is passed an invocationcontext object, used to read inputs, set outputs, write to logs, and read various metadata. In the v3 model, the context object is always the first argument passed to your handler.

Thecontext object has the following properties:

context.executionContext

Thecontext.executionContext object has the following properties:

context.executionContext.retryContext

Thecontext.executionContext.retryContext object has the following properties:

context.bindings

Thecontext.bindings object is used to read inputs or set outputs. The following example is astorage queue trigger, which usescontext.bindings to copy astorage blob input to astorage blob output. The queue message's content replaces{queueTrigger} as the file name to be copied, with the help of abinding expression.

{    "name": "myQueueItem",    "type": "queueTrigger",    "direction": "in",    "connection": "storage_APPSETTING",    "queueName": "helloworldqueue"},{    "name": "myInput",    "type": "blob",    "direction": "in",    "connection": "storage_APPSETTING",    "path": "helloworld/{queueTrigger}"},{    "name": "myOutput",    "type": "blob",    "direction": "out",    "connection": "storage_APPSETTING",    "path": "helloworld/{queueTrigger}-copy"}

module.exports = async function (context, myQueueItem) {  const blobValue = context.bindings.myInput;  context.bindings.myOutput = blobValue;};

import { AzureFunction, Context } from "@azure/functions";const queueTrigger1: AzureFunction = async function (  context: Context,  myQueueItem: string): Promise<void> {  const blobValue = context.bindings.myInput;  context.bindings.myOutput = blobValue;};export default queueTrigger1;

context.done

Thecontext.done method is deprecated. Before async functions were supported, you would signal your function is done by callingcontext.done():

module.exports = function (context, request) {  context.log("this pattern is now deprecated");  context.done();};

import { AzureFunction, Context, HttpRequest } from "@azure/functions";const httpTrigger: AzureFunction = function (  context: Context,  request: HttpRequest): void {  context.log("this pattern is now deprecated");  context.done();};export default httpTrigger;

We recommend that you remove the call tocontext.done() and mark your function as async so that it returns a promise (even if you don'tawait anything). As soon as your function finishes (in other words, the returned promise resolves), the v3 model knows your function is done.

module.exports = async function (context, request) {  context.log("you don't need context.done or an awaited call");};

import { AzureFunction, Context, HttpRequest } from "@azure/functions";const httpTrigger: AzureFunction = async function (  context: Context,  request: HttpRequest): Promise<void> {  context.log("you don't need context.done or an awaited call");};export default httpTrigger;

Each invocation of your function is passed an invocationcontext object, with information about your invocation and methods used for logging. In the v4 model, thecontext object is typically the second argument passed to your handler.

TheInvocationContext class has the following properties:

Retry context

TheretryContext object has the following properties:

For more information, seeretry-policies.

Note

If you use the alternative Node.jsconsole.log method, those logs are tracked at the app-level and willnot be associated with any specific function. Wehighly recommend that your usecontext for logging instead ofconsole so that all logs are associated with a specific function.

• JavaScript
• TypeScript

context.log(`Something has happened. Invocation ID: "${context.invocationId}"`);

context.log(`Something has happened. Invocation ID: "${context.invocationId}"`);

Track custom data

By default, Azure Functions writes output as traces to Application Insights. For more control, you can instead use theApplication Insights Node.js SDK to send custom data to your Application Insights instance.

const appInsights = require("applicationinsights");appInsights.setup();const client = appInsights.defaultClient;module.exports = async function (context, request) {  // Use this with 'tagOverrides' to correlate custom logs to the parent function invocation.  var operationIdOverride = {    "ai.operation.id": context.traceContext.traceparent,  };  client.trackEvent({    name: "my custom event",    tagOverrides: operationIdOverride,    properties: { customProperty2: "custom property value" },  });  client.trackException({    exception: new Error("handled exceptions can be logged with this method"),    tagOverrides: operationIdOverride,  });  client.trackMetric({    name: "custom metric",    value: 3,    tagOverrides: operationIdOverride,  });  client.trackTrace({    message: "trace message",    tagOverrides: operationIdOverride,  });  client.trackDependency({    target: "http://dbname",    name: "select customers proc",    data: "SELECT * FROM Customers",    duration: 231,    resultCode: 0,    success: true,    dependencyTypeName: "ZSQL",    tagOverrides: operationIdOverride,  });  client.trackRequest({    name: "GET /customers",    url: "http://myserver/customers",    duration: 309,    resultCode: 200,    success: true,    tagOverrides: operationIdOverride,  });};

import { AzureFunction, Context, HttpRequest } from "@azure/functions";import * as appInsights from "applicationinsights";appInsights.setup();const client = appInsights.defaultClient;const httpTrigger: AzureFunction = async function (  context: Context,  request: HttpRequest): Promise<void> {  // Use this with 'tagOverrides' to correlate custom logs to the parent function invocation.  var operationIdOverride = {    "ai.operation.id": context.traceContext.traceparent,  };  client.trackEvent({    name: "my custom event",    tagOverrides: operationIdOverride,    properties: { customProperty2: "custom property value" },  });  client.trackException({    exception: new Error("handled exceptions can be logged with this method"),    tagOverrides: operationIdOverride,  });  client.trackMetric({    name: "custom metric",    value: 3,    tagOverrides: operationIdOverride,  });  client.trackTrace({    message: "trace message",    tagOverrides: operationIdOverride,  });  client.trackDependency({    target: "http://dbname",    name: "select customers proc",    data: "SELECT * FROM Customers",    duration: 231,    resultCode: 0,    success: true,    dependencyTypeName: "ZSQL",    tagOverrides: operationIdOverride,  });  client.trackRequest({    name: "GET /customers",    url: "http://myserver/customers",    duration: 309,    resultCode: 200,    success: true,    tagOverrides: operationIdOverride,  });};export default httpTrigger;

ThetagOverrides parameter sets theoperation_Id to the function's invocation ID. This setting enables you to correlate all of the automatically generated and custom logs for a given function invocation.

HTTP and webhook triggers use request and response objects to represent HTTP messages.

HTTP and webhook triggers useHttpRequest andHttpResponse objects to represent HTTP messages. The classes represent a subset of thefetch standard, using Node.js'sundici package.

The request can be accessed in several ways:

• As the second argument to your function:

  • JavaScript
  • TypeScript

  module.exports = async function (context, request) {    context.log(`Http function processed request for url "${request.url}"`);

• From thecontext.req property:

  • JavaScript
  • TypeScript

  module.exports = async function (context, request) {    context.log(`Http function processed request for url "${context.req.url}"`);

• From the named input bindings: This option works the same as any non HTTP binding. The binding name infunction.json must match the key oncontext.bindings, or "request1" in the following example:

  {  "name": "request1",  "type": "httpTrigger",  "direction": "in",  "authLevel": "anonymous",  "methods": ["get", "post"]}

  • JavaScript
  • TypeScript

  module.exports = async function (context, request) {    context.log(`Http function processed request for url "${context.bindings.request1.url}"`);

TheHttpRequest object has the following properties:

The request can be accessed as the first argument to your handler for an HTTP triggered function.

async (request, context) => {    context.log(`Http function processed request for url "${request.url}"`);

async function helloWorld1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {    context.log(`Http function processed request for url "${request.url}"`);

TheHttpRequest object has the following properties:

In order to access a request or response's body, the following methods can be used:

The response can be set in several ways:

• Set thecontext.res property:

  • JavaScript
  • TypeScript

  module.exports = async function (context, request) {    context.res = { body: `Hello, world!` };

• Return the response: If your function is async and you set the binding name to$return in yourfunction.json, you can return the response directly instead of setting it oncontext.

  {  "type": "http",  "direction": "out",  "name": "$return"}

  • JavaScript
  • TypeScript

  module.exports = async function (context, request) {    return { body: `Hello, world!` };

• Set the named output binding: This option works the same as any non HTTP binding. The binding name infunction.json must match the key oncontext.bindings, or "response1" in the following example:

  {  "type": "http",  "direction": "out",  "name": "response1"}

  • JavaScript
  • TypeScript

  module.exports = async function (context, request) {    context.bindings.response1 = { body: `Hello, world!` };

• Callcontext.res.send(): This option is deprecated. It implicitly callscontext.done() and can't be used in an async function.

  • JavaScript
  • TypeScript

  module.exports = function (context, request) {    context.res.send(`Hello, world!`);

If you create a new object when setting the response, that object must match theHttpResponseSimple interface, which has the following properties:

You can also modify thecontext.res object without overwriting it. The defaultcontext.res object uses theHttpResponseFull interface, which supports the following methods in addition to theHttpResponseSimple properties:

The response can be set in several ways:

• As a simple interface with typeHttpResponseInit: This option is the most concise way of returning responses.

  • JavaScript
  • TypeScript

  return { body: `Hello, world!` };

TheHttpResponseInit interface has the following properties:

• As a class with typeHttpResponse: This option provides helper methods for reading and modifying various parts of the response like the headers.

  • JavaScript
  • TypeScript

  const response = new HttpResponse({ body: `Hello, world!` });response.headers.set("content-type", "application/json");return response;

TheHttpResponse class accepts an optionalHttpResponseInit as an argument to its constructor and has the following properties:

Prerequisites

• The@azure/functions npm package version 4.3.0 or later.
• Azure Functions runtime version 4.28 or later.
• Azure Functions Core Tools version 4.0.5530 or a later version, which contains the correct runtime version.

Enable streams

Use these steps to enable HTTP streams in your function app in Azure and in your local projects:

1. If you plan to stream large amounts of data, modify theFUNCTIONS_REQUEST_BODY_SIZE_LIMIT setting in Azure. The default maximum body size allowed is104857600, which limits your requests to a size of ~100 MB.

2. For local development, also addFUNCTIONS_REQUEST_BODY_SIZE_LIMIT to thelocal.settings.json file.

3. Add the following code to your app in any file included by yourmain field.

   • JavaScript
   • TypeScript

   const { app } = require("@azure/functions");app.setup({ enableHttpStream: true });

Stream examples

This example shows an HTTP triggered function that receives data via an HTTP POST request, and the function streams this data to a specified output file:

const { app } = require('@azure/functions');const { createWriteStream } = require('fs');const { Writable } = require('stream');app.http('httpTriggerStreamRequest', {    methods: ['POST'],    authLevel: 'anonymous',    handler: async (request, context) => {        const writeStream = createWriteStream('<output file path>');        await request.body.pipeTo(Writable.toWeb(writeStream));        return { body: 'Done!' };    },});

import { app, HttpRequest, HttpResponseInit, InvocationContext } from '@azure/functions';import { createWriteStream } from 'fs';import { Writable } from 'stream';export async function httpTriggerStreamRequest(    request: HttpRequest,    context: InvocationContext): Promise<HttpResponseInit> {    const writeStream = createWriteStream('<output file path>');    await request.body.pipeTo(Writable.toWeb(writeStream));    return { body: 'Done!' };}app.http('httpTriggerStreamRequest', {    methods: ['POST'],    authLevel: 'anonymous',    handler: httpTriggerStreamRequest,});

This example shows an HTTP triggered function that streams a file's content as the response to incoming HTTP GET requests:

const { app } = require('@azure/functions');const { createReadStream } = require('fs');app.http('httpTriggerStreamResponse', {    methods: ['GET'],    authLevel: 'anonymous',    handler: async (request, context) => {        const body = createReadStream('<input file path>');        return { body };    },});

import { app, HttpRequest, HttpResponseInit, InvocationContext } from '@azure/functions';import { createReadStream } from 'fs';export async function httpTriggerStreamResponse(    request: HttpRequest,    context: InvocationContext): Promise<HttpResponseInit> {    const body = createReadStream('<input file path>');    return { body };}app.http('httpTriggerStreamResponse', {    methods: ['GET'],    authLevel: 'anonymous',    handler: httpTriggerStreamResponse,});

For a ready-to-run sample app using streams, check out this example onGitHub.

Stream considerations

• Userequest.body to obtain the maximum benefit from using streams. You can still continue to use methods likerequest.text(), which always return the body as a string.

Hooks aren't supported in the v3 model.Upgrade to the v4 model to use hooks.

Use a hook to execute code at different points in the Azure Functions lifecycle. Hooks are executed in the order they're registered and can be registered from any file in your app. There are currently two scopes of hooks, "app" level and "invocation" level.

Invocation hooks

Invocation hooks are executed once per invocation of your function, either before in apreInvocation hook or after in apostInvocation hook. By default your hook executes for all trigger types, but you can also filter by type. The following example shows how to register an invocation hook and filter by trigger type:

const { app } = require('@azure/functions');app.hook.preInvocation((context) => {    if (context.invocationContext.options.trigger.type === 'httpTrigger') {        context.invocationContext.log(            `preInvocation hook executed for http function ${context.invocationContext.functionName}`        );    }});app.hook.postInvocation((context) => {    if (context.invocationContext.options.trigger.type === 'httpTrigger') {        context.invocationContext.log(            `postInvocation hook executed for http function ${context.invocationContext.functionName}`        );    }});

import { app, PostInvocationContext, PreInvocationContext } from '@azure/functions';app.hook.preInvocation((context: PreInvocationContext) => {    if (context.invocationContext.options.trigger.type === 'httpTrigger') {        context.invocationContext.log(            `preInvocation hook executed for http function ${context.invocationContext.functionName}`        );    }});app.hook.postInvocation((context: PostInvocationContext) => {    if (context.invocationContext.options.trigger.type === 'httpTrigger') {        context.invocationContext.log(            `postInvocation hook executed for http function ${context.invocationContext.functionName}`        );    }});

The first argument to the hook handler is a context object specific to that hook type.

ThePreInvocationContext object has the following properties:

ThePostInvocationContext object has the following properties:

App hooks

App hooks are executed once per instance of your app, either during startup in anappStart hook or during termination in anappTerminate hook. App terminate hooks have a limited time to execute and don't execute in all scenarios.

The Azure Functions runtime currentlydoesn't support context logging outside of an invocation. Use the Application Insightsnpm package to log data during app level hooks.

The following example registers app hooks:

const { app } = require('@azure/functions');app.hook.appStart((context) => {    // add your logic here});app.hook.appTerminate((context) => {    // add your logic here});

import { app, AppStartContext, AppTerminateContext } from '@azure/functions';app.hook.appStart((context: AppStartContext) => {    // add your logic here});app.hook.appTerminate((context: AppTerminateContext) => {    // add your logic here});

The first argument to the hook handler is a context object specific to that hook type.

TheAppStartContext object has the following properties:

TheAppTerminateContext object has the following properties:

Warning

Use theFUNCTIONS_WORKER_PROCESS_COUNT setting with caution. Multiple processes running in the same instance can lead to unpredictable behavior and increase function load times. If you use this setting, wehighly recommend that you offset these downsides byrunning from a package file.

• Windows
• Linux

• Azure CLI
• Azure portal

az functionapp config appsettings set  --settings WEBSITE_NODE_DEFAULT_VERSION=~22 \ --name <FUNCTION_APP_NAME> --resource-group <RESOURCE_GROUP_NAME>

az functionapp config set --linux-fx-version "node|22" --name "<FUNCTION_APP_NAME>" \ --resource-group "<RESOURCE_GROUP_NAME>"

Warning

If possible, avoid usinglanguageWorkers__node__arguments in Azure because it can have a negative effect on cold start times. Rather than using prewarmed workers, the runtime has to start a new worker from scratch with your custom arguments.

Note

As ECMAScript modules are currently a preview feature in Node.js 14 or higher in Azure Functions.

Configure function entry point

Thefunction.json propertiesscriptFile andentryPoint can be used to configure the location and name of your exported function. ThescriptFile property is required when you're using TypeScript and should point to the compiled JavaScript.

UsingscriptFile

By default, a JavaScript function is executed fromindex.js, a file that shares the same parent directory as its correspondingfunction.json.

scriptFile can be used to get a folder structure that looks like the following example:

<project_root>/ | - node_modules/ | - myFirstFunction/ | | - function.json | - lib/ | | - sayHello.js | - host.json | - package.json

Thefunction.json formyFirstFunction should include ascriptFile property pointing to the file with the exported function to run.

{  "scriptFile": "../lib/sayHello.js",  "bindings": [    ...  ]}

UsingentryPoint

In the v3 model, a function must be exported usingmodule.exports in order to be found and run. By default, the function that executes when triggered is the only export from that file, the export namedrun, or the export namedindex. The following example setsentryPoint infunction.json to a custom value, "logHello":

{  "entryPoint": "logHello",  "bindings": [    ...  ]}

async function logHello(context) {  context.log("Hello, world!");}module.exports = { logHello };

import { AzureFunction, Context } from "@azure/functions";const logHello: AzureFunction = async function (  context: Context): Promise<void> {  context.log("Hello, world!");};export default { logHello };

In the following example, the asynchronous methodfs.readFile is invoked with an error-first callback function as its second parameter. This code causes both of the issues previously mentioned. An exception that isn't explicitly caught in the correct scope can crash the entire process (issue #1). Returning without ensuring the callback finishes means the http response sometimes has an empty body (issue #2).

// DO NOT USE THIS CODEconst { app } = require('@azure/functions');const fs = require('fs');app.http('httpTriggerBadAsync', {    methods: ['GET', 'POST'],    authLevel: 'anonymous',    handler: async (request, context) => {        let fileData;        fs.readFile('./helloWorld.txt', (err, data) => {            if (err) {                context.error(err);                // BUG #1: This will result in an uncaught exception that crashes the entire process                throw err;            }            fileData = data;        });        // BUG #2: fileData is not guaranteed to be set before the invocation ends        return { body: fileData };    },});

// DO NOT USE THIS CODEimport { app, HttpRequest, HttpResponseInit, InvocationContext } from '@azure/functions';import * as fs from 'fs';export async function httpTriggerBadAsync(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {    let fileData: Buffer;    fs.readFile('./helloWorld.txt', (err, data) => {        if (err) {            context.error(err);            // BUG #1: This will result in an uncaught exception that crashes the entire process            throw err;        }        fileData = data;    });    // BUG #2: fileData is not guaranteed to be set before the invocation ends    return { body: fileData };}app.http('httpTriggerBadAsync', {    methods: ['GET', 'POST'],    authLevel: 'anonymous',    handler: httpTriggerBadAsync,});

In the following example, the asynchronous methodfs.readFile is invoked with an error-first callback function as its second parameter. This code causes both of the issues previously mentioned. An exception that isn't explicitly caught in the correct scope can crash the entire process (issue #1). Calling the deprecatedcontext.done() method outside of the scope of the callback can signal the function is finished before the file is read (issue #2). In this example, callingcontext.done() too early results in missing log entries starting withData from file:.

// NOT RECOMMENDED PATTERNconst fs = require("fs");module.exports = function (context) {  fs.readFile("./hello.txt", (err, data) => {    if (err) {      context.log.error("ERROR", err);      // BUG #1: This will result in an uncaught exception that crashes the entire process      throw err;    }    context.log(`Data from file: ${data}`);    // context.done() should be called here  });  // BUG #2: Data is not guaranteed to be read before the Azure Function's invocation ends  context.done();};

// NOT RECOMMENDED PATTERNimport { AzureFunction, Context } from "@azure/functions";import * as fs from "fs";const trigger1: AzureFunction = function (context: Context): void {  fs.readFile("./hello.txt", (err, data) => {    if (err) {      context.log.error("ERROR", err);      // BUG #1: This will result in an uncaught exception that crashes the entire process      throw err;    }    context.log(`Data from file: ${data}`);    // context.done() should be called here  });  // BUG #2: Data is not guaranteed to be read before the Azure Function's invocation ends  context.done();};export default trigger1;

Withasync andawait, you also don't need to call thecontext.done() callback.

// Recommended patternconst fs = require("fs/promises");module.exports = async function (context) {  let data;  try {    data = await fs.readFile("./hello.txt");  } catch (err) {    context.log.error("ERROR", err);    // This rethrown exception will be handled by the Functions Runtime and will only fail the individual invocation    throw err;  }  context.log(`Data from file: ${data}`);};

// Recommended patternimport { AzureFunction, Context } from "@azure/functions";import * as fs from "fs/promises";const trigger1: AzureFunction = async function (  context: Context): Promise<void> {  let data: Buffer;  try {    data = await fs.readFile("./hello.txt");  } catch (err) {    context.log.error("ERROR", err);    // This rethrown exception will be handled by the Functions Runtime and will only fail the individual invocation    throw err;  }  context.log(`Data from file: ${data}`);};export default trigger1;