Skip to content

SchoolPalm Module SDK

SchoolPalm Module SDK — Overview

What it is

The SchoolPalm Module SDK is a framework that enables feature modules to be plugged into the SchoolPalm platform in a structured and consistent way.

A “module” can provide:

  • UI screens (pages/components)
  • Backend actions (create, edit, list, workflows)
  • Business logic and data operations
  • Permissions and role-based behaviors

The SDK ensures that every module follows a standard integration model, so new features can be added without modifying or fragmenting the core platform.


Core Idea

In a modular system, the main challenge is not building features — it is integration.

Key questions include:

  • How does the platform discover modules?
  • How are requests routed to the correct module?
  • How is execution kept consistent across modules?
  • How do we prevent modules from breaking the system as they evolve?

The Module SDK solves these challenges by introducing:

  • A standardized module contract (manifest + conventions)
  • A predictable runtime execution flow
  • A controlled installation and registration process
  • Integration with a shared module registry system

Architecture (High-Level)

1. Module Description (Manifest)

Each module is defined using a manifest file that describes:

  • Module identity (name, key, namespace)
  • Capabilities (available actions/features)
  • Wiring information (providers, entry points)
  • Optional UI configuration (menus, navigation, dashboards)

This transforms a folder of code into a discoverable system component.


2. Module Registration & Discovery

The SDK works with a shared system called module-bridge, which enables:

  • Automatic namespace registration
  • Service provider loading
  • Module discovery at runtime
  • Platform-wide relation mapping

This removes the need to hardcode module locations inside the core system.


3. Runtime Execution Pipeline

When a request is made:

  1. The platform receives a route containing:
    • portal
    • module
    • action
  2. The SDK resolves the target module
  3. The requested action is mapped to module logic
  4. The module executes and returns a response

Responses may be:

  • JSON (API/AJAX requests)
  • Rendered pages (UI requests)

This ensures a consistent execution model across all modules.


4. UI Integration

The SDK supports unified UI rendering (commonly via Inertia), allowing modules to provide:

  • Dashboards
  • Interactive pages
  • Data-driven UI components

All module UIs are hosted through a standard rendering pipeline.


Why the SDK is needed

Without a standardized SDK, each module would require custom integration, leading to:

  • inconsistent routing logic
  • duplicated bootstrapping code
  • manual provider registration
  • unpredictable execution behavior
  • fragile platform scaling

The SDK solves this by ensuring:

  • consistent module structure
  • predictable runtime behavior
  • safe and repeatable installation
  • reduced platform coupling

Role of module-bridge

The module-bridge is the platform’s discovery and wiring layer.

The Module SDK depends on it to:

  • register module namespaces dynamically
  • load service providers automatically
  • manage snapshot/execution registries
  • build a unified relation registry for the platform

Conceptually:

  • module-bridge → Platform wiring & discovery layer
  • module-sdk → Module creation & execution layer

Value Proposition

The Module SDK enables a scalable modular ecosystem by:

  • accelerating module development
  • standardizing integration patterns
  • ensuring runtime consistency
  • reducing platform fragmentation
  • enabling safe long-term evolution of the system

One-line Pitch

SchoolPalm Module SDK is the standardized framework that turns feature code into installable, discoverable, and runtime-executable modules—integrated through module-bridge to ensure a scalable and non-fragmented platform architecture.