DOCSEARCHbyAlgolia
Submit Docs

LinaPro Documentation

website·Indexed 31 days ago

https://linapro.ai

Developer documentation for LinaPro version 0.5.x, a framework utilizing a domain-driven design approach to model core capabilities. It features a plugin system supporting both Source Plugins and Dynamic Plugins, a routing system built on GoFrame's ghttp.Server, and a comprehensive set of domain capabilities including AI, Auth, Storage, and Multi-tenancy.

Tokens
287.6K
Snippets
1.1K
Records
2K
Agent score
55%

What's inside LinaPro

  1. Overview of Specification-Driven Development (SDD)

    Specification-Driven Development (SDD) is an AI-native workflow based on the philosophy that specifications must exist before code, and code is driven into existence by those specifications. This prevents technical designs from becoming outdated by ensuring every feature iteration starts and ends with specification documents. These documents serve as the context for AI decision-making and are archived as baselines to ensure consistency in subsequent iterations.

  2. Overview of Specification-Driven Development (SDD)

    Specification-Driven Development (SDD) is an AI-native workflow where specifications exist before code, and code is driven by those specs. This prevents technical designs from becoming stale by ensuring every feature iteration starts and ends with spec documents. AI uses these documents for context and decision-making, and archived specs serve as constraints for future iterations to ensure consistency.

  3. Overview of LinaPro Dynamic Plugins

    Dynamic plugins in LinaPro are runtime-extensible plugins compiled into .wasm artifacts. They allow developers to upload, install, enable, disable, uninstall, and upgrade plugins at runtime without recompiling the core framework. These plugins run in a WASM sandbox and cannot directly access the host filesystem, network, or database; all interactions must occur via pluginbridge and hostServices authorization.

  4. Overview of LinaPro Source Plugins

    Source plugins are the recommended extension mechanism for LinaPro. They are compiled and deployed as Go source code alongside the core framework. They are ideal for long-term business modules, backend capabilities (organization, monitoring, content), and features requiring tight integration with core permissions, menus, and multi-tenancy. Because they require rebuilding and redeploying the core framework, they are not suitable for runtime hot-reloading or commercial binary distribution where source code must remain hidden.

  5. Overview of LinaPro SPI Architecture

    LinaPro uses a Service Provider Interface (SPI) pattern to separate capability contracts from their implementations. The host defines public interfaces for domain capabilities, while source plugins implement the business logic via provider factories.

    Key architectural constraints:

    • Source Plugins Only: Only source plugins can register SPI factories because they must implement Go interfaces and run within the host process.
    • Single Provider: Each capability can have only one provider; registering duplicates results in an error.
    • Lazy Construction: Provider instances are only created when a capability is first consumed to avoid startup dependencies.
    • Safe Degradation: If no provider is available, capabilities return empty results or an 'unavailable' status instead of nil or errors.
    • Provider Status: A provider can remain platform-enabled (via IsProviderEnabled) even if the plugin's business entry is disabled for a specific tenant.

  6. Overview of the LinaPro Plugin System

    The LinaPro plugin system is the core extension mechanism for delivering business capabilities. Plugins are self-contained modules that can define API routes, database resources, frontend pages, menu permissions, language packs, scheduled tasks, and lifecycle callbacks.

  7. Overview of Plugin Lifecycle Hooks

    Lifecycle declarations manage callback registration for plugin governance operations. Hooks are categorized into two types:

    • Before hooks: Used for validation. They can veto an operation by returning ok=false and a reason.
    • After hooks: Used for observation and cleanup; they cannot veto operations.

    Supported operations include Install, Upgrade, Disable, Uninstall, Tenant Disable, Tenant Delete, and Install Mode Change.

  8. Overview of Notification Capability entries

    The notification capability is available at runtime for Source and Dynamic plugins. It follows a read-write separation pattern where standard interfaces are read-only and administrative interfaces handle governed write operations (sending and deleting).

  9. Overview of LinaPro Source Plugins

    Source plugins are the recommended extension method for LinaPro. They are written in Go, compiled and deployed with the core framework, and use pluginhost to register routes, hooks, scheduled tasks, and governance logic. They are ideal for long-term business modules requiring high performance and tight integration with core framework permissions, menus, and multi-tenancy. Note that they require rebuilding and redeploying the core framework for updates and typically expose source code.

  10. Overview of LinaPro capability services

    The LinaPro core framework provides a set of stable capability services via the capability.Services interface. These services handle cross-cutting concerns including authentication, configuration, data storage, plugin governance, and notifications. Key design principles include:

    • Stable Boundaries: Plugins depend on contracts in the contract package, not internal implementations.
    • Plugin Isolation: Services like cache and configuration are automatically scoped to the plugin ID.
    • Safe Degradation: Framework capabilities (e.g., organization/tenant management) can be checked for availability via Available().
    • Read-only Consumption: Standard plugins receive read-only interfaces; write operations and DB query builders are generally not exposed through capability.Services.

  11. Overview of lina-vben admin workspace

    lina-vben is the built-in admin workspace for LinaPro. It serves as the standard UI expression layer for the lina-core API and enabled plugin APIs. It is designed to consume backend contracts (menus, permissions, configurations) rather than defining business logic. Developers can use lina-vben as their admin interface or replace it with a custom frontend, provided the new frontend adheres to the core framework's public RESTful API and permission model.

  12. Overview of APIDocService

    The APIDocService allows plugins to convert request routes (operation keys) into localized business semantics (Title and Summary) without needing access to the host's OpenAPI generator. It is used primarily for operation logs, audit logs, and admin console filters. The service operates at Runtime and is supported by both Source and Dynamic plugins.