Muonroi UI Engine: a manifest-driven UI runtime + rule-authoring web components (open-core)

Repository: https://github.com/muonroi/muonroi-ui-engine

Status: public repo, open-core (some packages are Apache-2.0 OSS, some are commercial-licensed).

Target audience: unknown (repo docs suggest teams building backend-driven UI + rule-authoring UIs).

Version: workspace 0.1.22 (from package.json); MVC package 0.1.0 (from .csproj).

Executive summary

Muonroi UI Engine is the frontend / host-integration layer of the Muonroi ecosystem. Its core idea is backend-driven UI: a host app fetches a manifest that describes navigation, screens, components, actions, and the component registry, then a runtime turns it into a render plan for your framework (React / Angular / PrimeNG).

The repo also contains open-core rule-authoring UI surfaces built as Web Components (Lit): decision tables, rule flow designer, FEEL playground, tracing, etc. These appear to require a commercial license / “activation proof” at runtime, while the base runtime + adapters stay usable without commercial dependencies.

Key features and use cases

Key features (from repo structure and deep map)

• Manifest schema (v1/v2) that models navigation groups, screens, components, actions, data sources, registry, auth profile, and more.
• Core runtime that resolves screens by route and checks what can render/execute.
• Framework adapters for:
  • React (@muonroi/ui-engine-react)
  • Angular (@muonroi/ui-engine-angular)
  • PrimeNG (@muonroi/ui-engine-primeng)
• Web Components (Lit) rule-authoring widgets (commercial modules), exposed via tags like:
  • <mu-decision-table>
  • <mu-rule-flow-designer>
  • <mu-feel-playground>
  • <mu-rule-trace-viewer>
• ASP.NET MVC bridge (Muonroi.Ui.Engine.Mvc) for server-rendered hosts: manifest models + helper extensions.

Practical use cases

• Backend-driven admin portals where navigation + screen composition are shipped from a server.
• Composable UIs across multiple frontend stacks: reuse the same manifest across React and Angular apps via adapters.
• Embedded rule-authoring experiences (decision tables / flow designer) inside an internal control plane.
• Server-rendered hosts that need to load a manifest and drive “what to show” in MVC views.

Architecture and main components

Big-picture (how the UI engine flows)

flowchart LR
  Host[Host app (React / Angular / MVC)] -->|fetch JSON manifest| Manifest[MUiEngineManifest]
  Manifest --> Runtime[MUiEngineRuntime]
  Runtime --> Plan[Render plan / layout plan]
  Plan --> Adapter[Framework adapter<br/>(React/Angular/PrimeNG)]
  Adapter --> UI[Actual UI components<br/>+ custom elements]
  UI -->|calls| APIs[Backend endpoints]

Monorepo layout (high level)

muonroi-ui-engine/
  packages/
    m-ui-engine-core/                 # OSS runtime + schema contracts
    m-ui-engine-react/                # OSS React wrappers
    m-ui-engine-angular/              # OSS Angular mappers
    m-ui-engine-primeng/              # OSS PrimeNG adapter
    m-ui-engine-rule-components/      # Commercial: decision tables, flow designer, FEEL, trace...
    m-ui-engine-rule-components-primeng  # Commercial: PrimeNG adapter for rule components
    m-ui-engine-signalr/              # Commercial: schema watcher via SignalR
    m-ui-engine-sync/                 # Commercial: CLI sync tooling
  src/
    Muonroi.Ui.Engine.Mvc/            # OSS .NET MVC bridge package
  tests/
    Muonroi.Ui.Engine.Mvc.Tests/      # tests mostly concentrated here (per repo README)
  REPO_DEEP_MAP.md                    # file-level map of the monorepo
  LICENSE / LICENSE-APACHE / LICENSE-COMMERCIAL

Core runtime package: what’s inside

The file-level map highlights core “building blocks” such as:

• contracts.ts: the manifest schema (MUiEngineManifest, MUiEngineScreen, MUiEngineAction, etc.).
• runtime.ts: MUiEngineRuntime (screen resolution, permission checks).
• bootstrap.ts: bootstrapper, manifest provider, schema watcher, telemetry.
• adapters.ts: render adapters + render-plan builders.
• license/MLicenseVerifier.ts: license verification used to gate commercial modules.

If you only read one file before diving deeper, start here:

• https://github.com/muonroi/muonroi-ui-engine/blob/main/REPO_DEEP_MAP.md

Optional commercial rule-authoring surface

The deep map lists many UI widgets shipped as custom elements (Lit). A typical flow is:

flowchart TD
  App[Host app] -->|bootstraps custom elements| Loader[MLoadRuleEngineCustomElements]
  Loader --> Gate[Commercial license check]
  Gate -->|license ok| Widgets[Decision table / Flow designer / FEEL / Trace widgets]
  Gate -->|not licensed| Prompt[Upgrade prompt / restricted UI]

Installation and quickstart

Build the monorepo locally (TypeScript workspace)

pnpm install
pnpm build

Notes:

• The root package.json indicates a workspace layout with packages/* and scripts that run workspace builds/tests.
• Tooling includes TypeScript and Vitest (for tests), and the repo references Vite configs for certain bundles.

Install the ASP.NET MVC host bridge

dotnet add package Muonroi.Ui.Engine.Mvc

Compatibility warning: the .csproj targets net9.0 (check your runtime/SDK availability).

Example usage

1) Bootstrapping rule-authoring custom elements from React

The README shows a React setup that loads custom elements and renders the flow designer:

import {
  MLoadRuleEngineCustomElements,
  MuRuleFlowDesignerReact
} from "@muonroi/ui-engine-react";

await MLoadRuleEngineCustomElements({ activationProof });

<MuRuleFlowDesignerReact
  graph={{
    nodes: [],
    edges: [],
    metadata: { version: 1, workflowName: "wf.orders" }
  }}
  apiBaseUrl="/api/v1"
  height={720}
/>;

What’s unknown: how activationProof is obtained and what exact fields it contains (it’s part of the commercial story).

2) A minimal (illustrative) manifest snippet

Based on the TypeScript contracts, a manifest is shaped roughly like this:

{
  "schemaVersion": "mui.engine.v2",
  "generatedAtUtc": "2026-04-14T00:00:00Z",
  "userId": "00000000-0000-0000-0000-000000000000",
  "tenantId": "tenant-a",
  "navigationGroups": [],
  "screens": [],
  "actions": [],
  "dataSources": [],
  "componentRegistry": {
    "components": {}
  }
}

3) MVC host: working with manifest models

The MVC package includes manifest models like MUiEngineManifest, MUiEngineNavigationGroup, MUiEngineScreen, etc. You can also use extension helpers like MVisibleItems() for view-level rendering logic:

@using Muonroi.Ui.Engine.Mvc
@using Muonroi.Ui.Engine.Mvc.Models
@model MUiEngineManifest

<nav>
  @foreach (var group in Model.NavigationGroups)
  {
    <h3>@group.GroupDisplayName</h3>
    <ul>
      @foreach (var item in group.MVisibleItems())
      {
        <li>@item.Title</li>
      }
    </ul>
  }
</nav>

Contribution guide and license

Contributing

The repo’s contributing guide highlights:

• Default branch: develop
• Prereqs: Node.js 20+, pnpm
• Usual workflow: pnpm install, pnpm test, pnpm build
• Keep the OSS/commercial boundary intact; add docs/tests when behavior changes.

Contributing guide:

https://github.com/muonroi/muonroi-ui-engine/blob/main/CONTRIBUTING.md

License (open-core / dual license)

The root license file describes a dual-license structure:

• OSS core + adapters: Apache 2.0 (LICENSE-APACHE)
• Commercial modules: Muonroi commercial license (LICENSE-COMMERCIAL)

License files:

• https://github.com/muonroi/muonroi-ui-engine/blob/main/LICENSE
• https://github.com/muonroi/muonroi-ui-engine/blob/main/LICENSE-APACHE
• https://github.com/muonroi/muonroi-ui-engine/blob/main/LICENSE-COMMERCIAL

Comparison to similar approaches (brief)

• Compared to microfrontend orchestrators (e.g., single-spa): Muonroi UI Engine is centered on a backend-driven manifest + runtime + component registry, not only on “mount multiple frontends into one shell.”
  
  Reference (microfrontends concept): https://single-spa.js.org/docs/microfrontends-concept/

• Compared to low-code/internal tool builders (e.g., Appsmith): Appsmith focuses on a visual app builder with drag-and-drop widgets + integrations, while Muonroi UI Engine looks like a programmable runtime + adapters with optional embedded rule-authoring widgets.
  
  Reference: https://www.appsmith.com/

• Compared to form builders (e.g., Form.io): Form.io’s open source core is strongly focused on form rendering/builder, whereas Muonroi UI Engine’s scope includes navigation/screen composition plus rule-authoring widgets (decision tables/flows).
  
  Reference: https://form.io/open-source/

Suggested tags and social blurb

Suggested dev.to tags

muonroi, typescript, webcomponents, react, angular, dotnet, lit, backenddrivenui, monorepo, opensource

Social blurb (3–5 lines)

Muonroi UI Engine is a manifest-driven UI runtime (open-core) that lets your backend describe navigation/screens/components—and renders them through React/Angular/PrimeNG adapters.

It also ships optional Lit-based rule-authoring widgets (decision tables, flow designer, FEEL playground, tracing).

If you’re exploring backend-driven UI + embeddable rule tooling, this monorepo is worth a look.

Repo: https://github.com/muonroi/muonroi-ui-engine

References

• Repo deep map: https://github.com/muonroi/muonroi-ui-engine/blob/main/REPO_DEEP_MAP.md
• single-spa microfrontends concept: https://single-spa.js.org/docs/microfrontends-concept/
• Appsmith: https://www.appsmith.com/
• Form.io open source: https://form.io/open-source/