Skip to main content

Development Approach

Torus Development​

The Torus Development Approach is a Vertical Agnostic General Purpose Development Platform aimed at building Enterprise-Grade and Citizen-Scale applications. To achieve this, applications must be “Always On”, scalable, performant on demand, and uphold the highest security standards.

Torus streamlines the Software Development Life Cycle (SDLC) by incorporating six foundational pillars, enabling developers to build robust applications efficiently.

Key Highlights for Easy Understanding​

  • Think of Torus as a toolbox that helps developers build complex applications easily.
  • Each Fabric is like a different workspace where developers perform specialized tasks.
  • Nodes are like building blocks that connect together to form a complete application.
  • Diagrams are like blueprints that guide how different parts of the application connect.
  • Artifacts are reusable code snippets that save time and effort.
  • Orchestration is the glue that brings everything together and ensures smooth operation.

Fabric​

A Fabric in Torus represents a group of tasks performed by developers with specific skill sets, contributing to a step in traditional application development. These tasks are represented using diagrams.

Technically, a Fabric abstracts complexity by unifying disparate components onto a common layer, making them easier to consume and understand.

Each Fabric in Torus enables developers to pick and choose components needed and stitch them together to build the final application.

Fabric Layers:​

  1. API Fabric - Handles API connections and data exchange.
  2. Data Fabric - Manages data relationships and storage.
  3. UI Fabric - Defines how the user interface looks and works.
  4. Process Fabric - Helps automate and streamline workflows.
  5. Automation & Integration Fabric - Enables system integrations and automations.
  6. Continuous Integration & Deployment (CI/CD) Fabric - Manages application deployment and updates.

Node​

A Node is the smallest tangible working unit of an application. Applications in Torus are built by connecting multiple nodes within each Fabric. Nodes in each Fabric are represented using diagrams and stored as Artifacts.

Diagram​

A Diagram represents the activities developers perform within a Fabric. Each Fabric can have one or more diagrams.

Diagram Types:​

S.NoFabricDiagramCode
1API FabricAPI Flow DiagramAF-AFD
2Data FabricEntity Relationship DiagramDF-ERD
Data Flow DiagramDF-DFD
3UI FabricUI Flow Diagram - WebUF-UFD-W
UI Flow Diagram - MobileUF-UFD-M
4Process FabricProcess Flow DiagramPF-PFD
5Automation & Integration FabricAutomation Integration Flow DiagramAIF-AIFD
6DeploymentInfrastructure as a Code DiagramCDF-IFD
Deployment Pipeline DiagramCDF-DPD
Environment DiagramCDF-ED

Artifact​

An Artifact is a tangible piece of code where different Nodes work together to perform a function. Artifacts are reusable, version-controlled elements that can be utilized across applications.

Orchestration​

Orchestration is a universal concept across all Fabrics. It enables developers to establish functionality and control at each Node while following the SEARC Principle:

  • S - Security
  • E - Event
  • A - Action
  • R - Rules
  • C - Custom Code

Building an Application​

Drawing a Data Flow Diagram (DFD)​

Steps:​

  1. Drag and drop an API Node from the Node Gallery into the workspace.
  2. Click the API Node and enter the required properties:
    • connectorName
    • linkParam (acts as a Primary Key, e.g., claimshdrid)
    • Operation Name (e.g., Get function)
  3. Set API properties:
    • Endpoint: http://192.168.2.18:3001/claims+header
    • Headers (optional fields for traditional API calls)
  4. Save Node Properties and store the DFD diagram under the Artifact menu.

Orchestration for DFD​

Objectives:​

  1. Create relationships between Artifacts across Fabrics.
  2. Enable SEARC capabilities.
  3. Build a ready-to-use Data Set for further processing.

Security Configuration:​

  • Policy-based access control is used instead of role-based access.
  • Security is managed through Templates and Profiles.
  • Policy rules include:
    1. Allow All
    2. Block All
    3. Allow Only This
    4. Block Only This

Actions in Orchestration:​

On selecting an Artifact and navigating to the Actions Tab, developers can configure:

  • Locking: Prevents multiple users from overriding data.
  • TTL (Time-to-Live): Defines lock duration.
  • Pagination: Controls data loading on UI screens.

Note: Since this is an In-Memory Design, locking prevents data inconsistency when multiple users access the same record.

Event​

Event is one of the most powerful state enablement functionalities that help define a flow.

Target Data Set​

In the presented screen, we observe the Target Data Set where:

  • Artifacts available in the Data Set and associated nodes are listed.
  • Each node has a specific role:
    • Start
    • API Node
    • End

Processing Capabilities​

The processing capabilities enable handling data at the node level, allowing fundamental pre-processing before data set creation.

  • Event Processing (if needed)
  • Filtering
  • Rule Engine (if needed)
  • Custom Code

Nodes Applicable for Data Fabric​

  1. DB Connection
  2. API Node
  3. Stream Data Connection
  4. File Data Extraction
  5. Decision Node – Validations & Logic
  6. Scheduler Node – Identifying repeatable actions

UI Fabric​

The UI Fabric is designed to create the UI screens and layout for the application.

UI Fabric Process​

  1. Node Gallery

    • Displays all available UI components along with their version numbers.
    • Version number indicates the number of property parameters the component can handle.

  2. Artifact Creation

    • Components are dragged and dropped to create UI Artifacts.
    • Components are available for both Web and Mobile.

  3. Group Component

    • The first step is dragging a Group Component, which serves as a canvas.
    • Additional components are placed within this group.

  4. Node Properties

    • Properties must be updated for each component.
    • Positioning Properties:
      • Name
      • Description
      • Layout Flag
      • Column Start, Column End
      • Row Start, Row End
      • Style Gap, Style Height, Style Width, Style gridAutoRows

  5. Data Entry Node Categories

    • Styling
    • Positioning
    • Event Handling
    • Validation

Event Handling in UI Fabric​

  • On Click Event (e.g., Save Button)
  • Save Handler Execution
  • UI Component Update upon save
  • Success Message Generation

Data Storage​

  • Data is stored in memory, accessible via API Fabric.
  • API Endpoints are dynamically generated and configured.

Orchestration​

Source & Destination Mapping​

  • Source: Data Sets created previously.
  • Destination Target: UI components/screens.
  • Orchestration maps the source dataset to the UI component.

Security Management​

For each node, user access is determined based on:

  • Allow All
  • Block All
  • Allow Only This
  • Block Only This

If a group is blocked, all sub-nodes will be blocked.

Rule Engine & Expression Editor​

  • Expression Editor: Custom logic.
  • Rule Engine: Define rules and actions triggered by events.
  • Example: Sum of Category Amount displayed in Total Claims.
  • Rules: List only values greater than 2000.
if (totalClaims > 2000) {
  showListComponent();
}

Process Flow​

Scenario: A user submits a claim; if the amount is greater than 1000, it requires manager approval.

Workflow Nodes​

  1. Start Node
  2. Human Task Node (Claim Entry Form)
  3. Account Validation Node (Checks if claim > 1000)
  4. HR Approval Form (Triggered via Rule Engine)
  5. Check Approval Status
  6. Trigger Email Notification
  7. End Node

AI Fabric Integration​

  • Torus Connector: Reads data from a pre-determined stream.
  • Email/SMS Connector (N8N): Sends notifications based on approval status.
  • Schedule Node: Executes every 15 seconds.

Deployment Fabric​

Deployment Diagrams​

  1. Infrastructure Diagram (IFD)

    • On-Premise, AWS, Azure, Google, OpenShift
    • Uses Terraform Standard

  2. Environment Diagram

    • Different environments like Torus Dev Env (Local), Torus Test Env (Azure)

  3. Deployment Pipeline Diagram

    • Continuous Integration (Source Code Updates)
    • Continuous Deployment (Integrating SonarQube, Trivy, Deployment Steps)

Available Deployment Nodes​

  • Redis
  • MinIO
  • GitHub, Bitbucket, GitLab

Deployment Pipeline Diagram (DPD)​

Overview​

The Deployment Pipeline Diagram (DPD) defines the sequence in which our code moves to its final destination. Our Node Gallery is visible, ensuring that each step is connected seamlessly. The generated code is maintained in GitHub.

As illustrated in the diagram, we sequentially connect from the Start Point to GitHub and the underlying system software.

Node Properties​

GitHub Node​

On selecting GitHub, the key node properties include:

  • GitRepo_URL
  • GitRepo_USRNAME
  • GITREPO_Token
  • GitRepo_Authemail
  • GitRepo_Authname
  • GitRepo_Branch

Depending on the service provider, the node properties are dynamically updated. The objective is to gain access to the environment, retrieve relevant information, and push updates accordingly.

Postgres Node​

The Postgres node establishes a database connection and creates the required database details.

  • Postgres_Host
  • Postgres_Port
  • Postgres_Username
  • Postgres_Password
  • Postgres_DatabaseName
  • Schema Name

Executing this node with the above parameters enables access to the DB, and all subsequent database-related actions will read and write accordingly.

Redis Node​

This node facilitates In-Memory Technology Processing, with properties similar to Postgres:

  • Host
  • Port
  • Username
  • Password

Backend Code Generation (NestJS)​

This node is responsible for generating backend code for database interactions and APIs. The code adheres to NestJS standards.

MinIO – Object Storage​

MinIO provides storage for documents, logs, images, and data. Even if the application does not require MinIO for business functions, it will still be configured for logs and audit trails (NFR).

MinIO Setup Properties:

  • Host
  • Port
  • UseSSL
  • MinIO Accessory
  • MinIO SecretKey

Assembler​

Once the DPD is defined, it is updated in the Assembler.

Key Functions of the Assembler​

  1. Connects all Artifacts in the Deployment Diagram.
  2. Updates App Group, App, and Version.
  3. Fixes a DPD against a tenant.
  4. Allows switching pipelines for custom tenants.

The first menu bar displays all available menus. Admin and Logs are default menus, while users can create additional menus.

Example Menu: Claim Processing

  • Claim Collection (First Module – Collects Claim Requests)
  • Claim Approval (Second Module – Approves Claims)

Diagrams and API Assignments​

  • DF (Data Flow Diagram)
  • UF (UI Flow Diagram)
  • PF (Process Flow Diagram)

Since DF and PF are linked to UF via Source/Target, assigning UF assembles the entire application.

API Selection​

  • Select all required APIs.
  • APIs generated via ERD are listed and allocated.

Build and Deploy​

  1. Click on Build
  2. Assign the version
  3. Code Generation and Deployment happen in a single click
  4. User accesses the deployment environment URL to experience the application

What is Torus?​

Torus is a General-Purpose Low-Code Citizen Scale & Enterprise-Grade Application Development Platform that delivers:

  • No Vendor Lock-In
  • Source Code Availability
  • Beautiful Web and Mobile Applications

Torus enables developers to build applications with a Drag and Drop Editor, offering an In-Memory, Event-Driven, Microservices Architecture that supports On-Prem, Cloud-Agnostic, and Hybrid environments with one-click deployment.