VOOZH about

URL: https://dev.to/muonroi/muonroi-ui-engine-a-manifest-driven-ui-runtime-rule-authoring-web-components-open-core-k9f

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

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:

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:

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