NaaP architecture

NaaP micro-frontend architecture: the Next.js 15 shell, ShellContext interface, UMD plugin loading, and the request flow from browser to database.

Micro-frontend design

NaaP is a micro-frontend architecture. The shell application is a Next.js 15 host. Plugins are compiled to UMD bundles and loaded at runtime via a plugin registry. Each plugin gets a ShellContext object on mount - this is the entire interface between a plugin and the platform.

The shell provides these services to every plugin via ShellContext:

interface ShellContext {
  auth: IAuthService;           // Authentication and authorisation
  navigate: NavigateFunction;   // Client-side navigation
  eventBus: IEventBus;          // Inter-plugin communication
  theme: IThemeService;         // Theme management
  notifications: INotificationService; // Toast notifications
  integrations: IIntegrationService;   // AI, storage, email
  logger: ILoggerService;       // Structured logging
  permissions: IPermissionService;     // Permission checking
  tenant?: ITenantService;      // Tenant context
  team?: ITeamContext;          // Team context
}

Plugins own a full vertical slice: frontend React components, backend API logic, and an isolated PostgreSQL schema within the shared database. In production (Vercel), plugin backends run as Next.js API route handlers at /api/v1/[plugin-name]/*. In local development, the shell proxies the same routes to standalone Express backends on ports 4001-4012.

The following diagram shows the complete request flow from browser to database.

Installed plugins

NaaP ships with 12 plugins covering developer, operator, monitoring, and governance use cases. The Plugin Marketplace plugin manages installation of additional community plugins.

The building a plugin page covers the CLI, scaffold commands, and SDK hooks for creating your own plugin.