DOCSEARCHbyAlgolia
Submit Docs

SolidX Developer Documentation

website·Indexed 30 days ago

https://docs.solidxai.com/

Developer guides and references for extending and customizing SolidX. Includes documentation on backend customization (custom controllers, services, repositories, and providers for email, SMS, and WhatsApp), frontend customization (custom views, widgets, and Redux integration), and code generation from data models.

Tokens
146.2K
Snippets
555
Records
910
Agent score
50%

What's inside SolidX

  1. Overview of SolidX Testing Architecture

    SolidX testing is implemented as a shared execution engine with pluggable adapters and step registries. It uses a layered execution pipeline to support both API and UI testing using the same scenario format, interpolation rules, and reporting flow.

    Execution Flow:

    1. Metadata: Defines what should run (fixtures, scenarios, roles).
    2. Runner: Prepares the runtime, adapters, and registries.
    3. Engine: Executes normalized steps against a shared context.
    4. Adapters: Interface with external systems (HTTP services or the browser).
    5. Resource Store: Persists values between steps.
    6. Reporter: Consumes lifecycle events to produce output.

  2. Overview of SolidX Kanban View

    The Kanban View in SolidX is a metadata-driven interface that presents model records in a kanban format. It is auto-generated based on model and field definitions and is configured via a structured JSON layout. It supports searching, filtering, sorting, pagination, data import/export, and custom action buttons.

  3. Overview of the solidctl CLI

    The solidctl CLI is the main operational control surface for SolidX projects, used from the project root. It manages the entire project lifecycle across five main command families:

    • Bootstrap: Project creation and building (create-app, build).
    • Platform lifecycle: Metadata seeding and project inspection (seed, info).
    • Development workflow: Code generation and dependency updates (generate, upgrade).
    • Testing workflow: Environment preparation and scenario execution (test).
    • AI workflow: Running the SolidX AI agent (agent).
    # Top-level help
solidctl --help

# Command-specific help
solidctl <command> --help

  4. Overview of SolidX Code Generation and Conventions

    SolidX employs two different strategies for backend and frontend development:

    1. Backend (solid-api): Metadata-owned scaffolding. SolidX uses metadata to generate and maintain NestJS modules, controllers, services, DTOs, entities, and repositories. This code can be safely regenerated to align with metadata changes.
    2. Frontend (solid-ui): Convention-driven. The UI is not scaffolded model-by-model. Instead, it follows a specific structure (e.g., *.ui-module.ts files) so that project-specific modules, routes, and Redux pieces can be discovered and registered dynamically by @solidxai/core-ui.

  5. Overview of SolidX Security Rules

    Security rules in SolidX provide record-level visibility and filtering, acting as row-level guardrails on top of role-based access. While permissions determine if a user can invoke an action, security rules determine which specific records that user can see or act upon. These rules are defined in the metadata file at the root under the securityRules key.

  6. Overview of SolidX Low-Code Platform

    SolidX is an enterprise-focused, low-code development platform designed for web applications. It is architected to follow standard best practices and an open-source stack development workflow to provide developers with 100% flexibility and avoid vendor lock-in associated with proprietary low-code tools.

  7. Overview of the SolidX testing system

    SolidX uses a metadata-driven testing system where API and UI tests are treated as different adapters on top of a shared testing engine and scenario model. This allows for shared assertions, utility steps, and managed test data setup/teardown. The system supports automated API testing and frontend end-to-end testing via Playwright.

  8. Overview of Institute Onboarding workflow

    The onboarding process is a multi-tenant architecture managed by a Super Admin. The Super Admin is responsible for onboarding the institute and creating initial admin users. Once onboarded, Institute Admins take ownership to manage their specific institute's data, including fee types, branding, and configuration. Institute Admins are restricted to seeing and managing only their own institute's data.

  9. Overview of School Fees Portal Payment Initiation

    The payment initiation feature allows Institute Admins to manage student payment collections. Key capabilities include bulk creation of payment requests via Excel upload, automatic student record creation/updates, support for multiple fee types per collection, and automated email notifications to parents. The system supports both Cash and Payment Gateway modes and manages payment statuses (Pending, Partially Paid, Fully Paid) and late fee calculations based on due dates.

  10. Overview of SolidX Test Hub

    Test Hub is a product module designed to verify if an application is ready for release by testing critical customer journeys (e.g., signing in, making payments, submitting applications, or completing orders). It allows teams to create test scenarios using plain language via a connected MCP AI assistant. Tests can be executed manually, automatically on a schedule, or as part of a pre-release check. Key benefits include reducing manual testing time, early issue detection, and providing clear pass/fail results with replays for troubleshooting.

  11. Overview of the School Fees & Payments Platform

    The School Fees & Payments Platform is a multi-tenant solution for educational institutes to digitize fee collection. A single deployment serves multiple institutes sharing one database, with data segregation enforced at the platform level. It consists of two primary interfaces:

    1. Admin Portal: Used by Super Admins and Institute Admins to onboard institutes, configure fee structures, manage student records, initiate bulk payment collections via Excel, and perform reconciliation.
    2. Student Portal: A public-facing interface where students/parents authenticate via email OTP to view dues, review payment history, and make online payments via integrated gateways.

  12. Overview of SolidX Form View Events

    Form view function extensions allow developers to react to lifecycle events in a SolidX form. These handlers can be used to read or mutate form data (via Formik), dynamically adjust the layout (hide/show/move fields) using the SolidViewLayoutManager, or coordinate with custom widgets. Handlers are authored as listener functions, registered in the UI module manifest, and referenced in the form view layout JSON.