Azure Function App Structure: function_app.py vs __init__.py with function.json

Recently I have been playing a lot of Azure FunctionApp’s and specifically for simple Automation creating Functions using Python.

This article explores the differences between using a single function_app.py file versus organizing your code with an __init__.py file and a function.json configuration file.

When deploying an Azure Function App, the structure and organization of your code are critical to ensure that the functions are correctly recognized and executed by the Azure Functions runtime. These approaches differ in how functions are triggered and how the runtime expects your code to be structured.

1. Default Folder Structure with function_app.py

In this approach, all the function logic resides in a single Python script, typically named function_app.py. This structure is commonly used for simple scenarios or when you want to keep everything in one file for ease of management.

Folder Structure:

MyFunctionApp/
│
├── function_app.py
├── host.json
├── local.settings.json
├── requirements.txt
├── .funcignore
├── .gitignore
└── .vscode/

function_app.py Example:

In this setup, the function is defined directly inside the function_app.py file, and the function app will execute this file when triggered via HTTP, timers, or other events.

import azure.functions as func
import logging

def main(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Function triggered.')
    return func.HttpResponse("Hello from Azure Function!", status_code=200)

Pros of function_app.py:

• Simplicity: All the function logic is contained in one file, making it easy to understand and manage for small applications.
• Quick Setup: Minimal configuration is required, as the function app directly executes the code in the function_app.py file.

Cons of function_app.py:

• Limited Scalability: As the application grows, maintaining all logic in a single file can become cumbersome.
• Reduced Modularity: This structure lacks a clear separation of concerns, making it less suitable for larger or more complex applications.
• Limited extensibility: The default structure doesn’t provide a clear separation of concerns or modularity for larger applications.

2. Using __init__.py with function.json

For more complex applications, or when you need a modular structure, you can use an __init__.py file (as part of a Python package) along with a function.json file. This approach allows for better organization and more granular control over function triggers and bindings.

Folder Structure:

MyFunctionApp/
│
├── myfunction/
│   ├── __init__.py
│   ├── function.json
│
├── host.json
├── local.settings.json
├── requirements.txt
├── .funcignore
├── .gitignore
└── .vscode/

__init__.py Example:

In this structure, the core logic of your function resides inside the __init__.py file. You can import other modules or add additional code as needed.

import azure.functions as func
import logging

def main(req: func.HttpRequest) -> func.HttpResponse:
    logging.info('Function triggered in __init__.py.')
    return func.HttpResponse("Hello from Azure Function in __init__.py!", status_code=200)

function.json Example:

The function.json file is crucial in defining the specific bindings and configuration for the function. It allows Azure Functions to know how the function should be triggered and what bindings (e.g., HTTP, Blob, Queue) to use.

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

Pros of __init__.py and function.json:

• Modularity: Code can be organized into packages, making it easier to maintain and scale.
• Flexible Bindings: The function.json file allows for detailed configuration of triggers and bindings, enabling integration with various Azure services (e.g., Blob Storage, Service Bus, Cosmos DB).
• Scalability: This structure supports multiple functions, each with its own __init__.py and function.json, making it ideal for larger applications.

Cons of __init__.py and function.json:

• Increased Complexity: The additional files and folder structure can make the project more complex, which may not be necessary for simple use cases.
• Configuration Overhead: Managing both Python code and configuration files requires extra attention during development and deployment.

Key Differences:

+-------------------+-------------------------------------------+------------------------------------------+
|   Aspect          |       function_app.py                     |   __init__.py with function.json         |
+-------------------+-------------------------+------------------------------------------------------------+
| Code Organization | Single file for all logic.                | Modular structure with separate folders. |
| Configuration     | Minimal setup; no function.json required. | Requires function.json for bindings.     |
| Triggers/Bindings | Simpler, limited to basic triggers.       | Supports complex triggers and bindings.  |
| Scalability       | Suitable for small apps.                  | Ideal for larger, scalable applications. |
+-------------------+-------------------------------------------+------------------------------------------+

By choosing the right structure for your Azure Function App, you can ensure better maintainability, scalability, and alignment with your application’s requirements.

By organizing your function app this way, you make your codebase more maintainable, especially when adding new functions or integrating with various Azure services.

Some of the links for reference:

Visual Studio Code: Open _Init_.py instead of function.json by default