Configuration

Binacle.Net is designed for flexibility, with many optional features that can be activated as needed. Most features are specialized and reside within modules, which may have compatibility limitations depending on your stack, technologies, or databases.

Configuration files are located in the Config_Files folder, or in the container at /app/Config_Files.

Binacle.Net’s modular architecture allows for additional functionality and customization options through its various modules.

Core

At its foundation, Binacle.Net provides the API functionality outlined in About the API. The core also supports customization of presets and includes the Swagger UI, which is disabled by default.

• Presets: For instructions on customizing presets, see Customization: Presets.

• Swagger UI: To enable Swagger UI, you can either set the environment variable SWAGGER_UI=True or update the Features.json file as follows:

{
  "Features": {
    "SERVICE_MODULE": "NotSet",
    "SWAGGER_UI": "True",
    "UI_MODULE": "NotSet"
  }
}

Diagnostics Module

The Diagnostics Module offers logging, health checks, and telemetry. This module is always active and cannot be disabled, but individual features—such as health checks and telemetry—must be manually enabled. Logging is the default feature.

For detailed configuration instructions, see Configuring the Diagnostics Module.

Service Module

The Service Module is designed for public environments, introducing rate limiting on calculation endpoints and user authentication to allow authenticated users to bypass rate limits. This module requires a database to function.

For setup instructions, see Setting up the Service Module.

UI Module

The UI Module adds a user interface, including a visualizer demo for the Packing function, allowing users to see the packing process in action.

For detailed setup instructions, see Setting up the UI Module.

Typical Use Cases

While the Core and Diagnostics modules are fundamental to all deployments, other modules like the Service and UI modules may not be necessary in most environments. For example, public-facing features like rate limiting and user authentication are often unnecessary in controlled, internal systems. Similarly, the UI Module may not be needed if interactions with Binacle.Net are primarily through the API.

In many cases, Binacle.Net will likely be used primarily for its core API functionality and diagnostics, with other modules only activated based on specific needs, such as public API exposure or packing visualization.

Conclusion

Binacle.Net's modular design allows you to tailor the API to your specific requirements. Whether you need enhanced diagnostics, public environment support, or a user-friendly interface for packing visualization, each module offers flexibility and can be enabled as needed. Refer to the relevant configuration guides to ensure a smooth setup and optimal functionality within your environment.