Introduction

LinaPro's component design centers on one principle: stable foundation, extend on demand. Platform-level capabilities are built into the core framework; business capabilities are delivered as self-contained components; components collaborate through explicit contracts with no hidden coupling.

This approach yields several key characteristics:

Clear boundaries, independently replaceable. The frontend workspace, backend core framework, and plugin system each have a well-defined scope of responsibility. The workspace depends only on the core framework's public API; plugins depend only on the stable extension interfaces the core framework publishes. Any layer can be upgraded or replaced without breaking the others.

Self-contained capabilities, opt-in delivery. Each business component (plugin) encapsulates its own API routes, database resources, frontend pages, menu permissions, language packs, and scheduled tasks — installed and uninstalled through the plugin lifecycle without touching core framework code. Official capabilities ship as independent plugins, so unused features never enter the deployment artifact.

Platform capabilities out of the box. Authentication, RBAC, multi-tenancy, scheduling, i18n, cluster coordination, and API documentation are all built into the core framework. Business plugins consume these directly without reimplementing them.

Dual-mode plugins balance flexibility and performance. Long-lived business modules use source plugins compiled into the core framework for native Go performance. When hot-loading or commercial binary distribution is required, WASM dynamic plugins fill that role — both modes share a single governance surface.

Related Topics

📄️Core Host

its responsibility boundaries, runtime request flow, startup and loading sequence, built-in platform capability matrix, plugin extension surfaces, and collaboration with the admin workspace, source plugins, WASM dynamic plugins, PostgreSQL, and Redis. It helps developers build a system-level map before reading deeper pages on configuration, permissions, API documentation, scheduled tasks, internationalization, multi-tenancy, the plugin system, and distributed architecture.

📄️Admin Workspace

the standard frontend consumer of the core framework service and plugin system, covering access control, system settings, job scheduling, multi-tenant management, plugin governance, developer center, and dynamic plugin pages, while maintaining consistency with backend API contracts, menu permissions, and I18N resources.

🗃Plugin System

5 items

📄️Distributed Architecture

how to switch between single-node and cluster mode, the Redis coordinator, leader election, node responsibilities, cache revision, distributed locks, key-value cache, scheduled task execution scope, and the horizontal scaling process — helping developers understand how business code can scale to multi-node deployment with zero modifications.

📄️Configuration

how config.yaml drives the HTTP server, logging, database, JWT authentication, sessions, monitoring, health probes, scheduling, public admin workspace frontend configuration, internationalization, cluster coordination, file uploads, and plugin governance, with the key configuration boundaries to review before production deployment.

📄️Routing

routing management strategy of the LinaPro core framework service, including the /api/v1 prefix for core framework control-plane APIs, the unified /x/{plugin-id}/... plugin API namespace, the built-in middleware pipeline, layered protected-route design, inline API attribute management via g.Meta struct tags, and the different integration approaches for source-plugin custom non-reserved routes and dynamic-plugin route contracts.

📄️Permission

permission management strategy of the LinaPro core framework service, including the issuance, parsing, and revocation of dual JWTs (Access Token and Refresh Token), lifecycle management of both token types, online session management via hot-state storage, the design of the RBAC role-permission model (three-tier relationship: role → menu → permission), token-scoped access context caching with revision-based invalidation, declarative API permission management via g.Meta struct tags and the Permission middleware enforcement flow, and menu permission management (menu types, role-menu associations, permission trees, and data scope control) — giving developers a complete understanding of the authentication and authorization system.

📄️Static Assets

how the core framework packages runtime resources and admin workspace build output with Go Embed, how plugins explicitly publish public static resources through public_assets, and how the /admin workspace entry, /x plugin API namespace, /x-assets public plugin asset namespace, source-plugin custom routes, and dynamic-plugin frontend resources stay separated. It helps developers design plugin pages, public assets, and cache/version policies correctly.

📄️API Reference

the core framework, source plugins, and WASM dynamic plugins are unified into a single OpenAPI document through g.Meta contracts, permission tags, API doc i18n resources, the in-workspace developer center debugging page, and third-party tool import.

📄️Multi Tenant

how the core framework bizctx, TenantFilterService, tenant_id filtering interface, default platform tenant, official multi-tenant source plugin, tenant impersonation, plugin multi-tenant manifest fields, and the current Pool shared-database model work together.

📄️Cron Tasks

task types, cron expressions, task groups, execution logs, built-in tasks, source plugin and dynamic plugin task declarations, master_only and all_node execution scopes, singleton and parallel concurrency strategies, and cluster scheduling behavior.

📄️I18N

how core framework language packs, plugin language packs, dynamic plugin language resources, API documentation translations, runtime caching, locale configuration, and frontend language switching work together, and what resource boundaries teams must maintain when adding new languages.