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.

Here’s the directory tree structure:

app
└── Config_Files
    ├── Features.json
    ├── Presets.json
    ├── DiagnosticsModule
    │   ├── ConnectionStrings.json
    │   ├── HeathChecks.json
    │   └── Serilog.json
    ├── ServiceModule
    │   ├── ConnectionStrings.json
    │   ├── JwtAuth.json
    │   ├── RateLimiter.json
    │   └── Users.json
    └── UiModule
        └── ConnectionStrings.json

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 Configuration: 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 Configuration: 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 Configuration: 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 Configuration: 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.

Configuration

You can configure the Service Module either by editing the appropriate configuration file or by setting environment variables.

To modify a configuration file, you’ll need to use a bind volume mount to ensure the file is accessible and persists across deployments.

Warning

Environment variables will always override settings in configuration files. Be mindful of this when deploying or modifying settings.

Exception: The settings in Features.json are not overridden by environment variables. Changes to features will take immediate effect if they are set to true or false.

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.