Cube Architecture & Implementation

Cube's brilliance lies in its automated, type-safe abstraction layer that eliminates repetitive boilerplate code.

How API Calls Are Built?

All resources are statically defined at compile time using a macro system. This ensures consistency and prevents runtime errors.

// Example: AccessControl/AccessControlEntry has full CRUD
resource!("AccessControl", "AccessControlEntry", FULL);

The previous resource macro produce the following endpoints.

GET    /api/AccessControl/AccessControlEntry
GET    /api/AccessControl/AccessControlEntry/{id}
POST   /api/AccessControl/AccessControlEntry
PUT    /api/AccessControl/AccessControlEntry/{id}
DELETE /api/AccessControl/AccessControlEntry/{id}

This matters because this allows us to get a very small codebase while having access to all APIs. It made it easy to update if new API endpoints are released by Netwrix. Compile-time safety guarantees resource definitions never go stale.

CLI

The cube binary dynamically generates API calls at runtime. It abstracts complex API interactions into intuitive commands. For example, executing the following command:

cube AccessControlEntry list

Automatically maps to the corresponding RESTful endpoint:

GET /api/AccessControl/AccessControlEntry

---

MCP Server: Dynamic Tool Generation

The cube-mcp crate dynamically generates tools at runtime based on the Resource registry.

Name Mapping: PascalCase → snake_case

Tools are prefixed and namespaped consistently:

usercube_<action>_<resource_snakecase> 
Examples:
→ usercube_list_entitytype  
→ usercube_get_connecteddeviceprofile
→ usercube_create_provisioningpolicy_compositerole
→ usercube_delete_job_taskinstancetaskdimensionassociation

Dynamic Schema Generation

Each tool type has a standardized schema automatically constructed. The schemas encode:

Param Type	Description Example	Optional?
query	"Search query"	Yes ✓
id	"Resource ID"	No ✗ (for get/update/delete)
page_size	"Results per page"	Yes ✓
continuation_token	Pagination token	Yes ✓

---

Production-Ready Patterns Demonstrated in Cube

Pattern	Purpose
Static Resource Registry	Compile-time validation, no runtime discovery overhead
Type-safe API methods	Prevents malformed requests before compilation
Capability Flags	Runtime permission checking without network calls
Authentication Factory Method	Single place to modify token handling
Generic Query Handling	Usercube-specific params centralized in one location
Verbose Logging Hook Point	Debug mode implemented via optional callback