Integration Patterns

Integration Patterns

Forsetti supports four deployment patterns. The key decision is whether users should see the Forsetti shell or only app-owned UI.

Pattern Matrix

Pattern	User Sees	Modules Active	Best For
A. Single-module app	App-owned module UI	One app module	Most production applications.
B. Multi-module single app	One dedicated UI/app module plus background services	One active UI/app module and many service modules	Apps with cleanly separated services.
C. Developer testing	Forsetti shell and module switcher	Multiple modules for testing; active UI can change	Development and QA.
D. Dashboard deployment	Dashboard or launcher shell	Multiple independent app modules over time	Portal-style products where users choose apps.

Pattern A: Single-Module App

flowchart LR
    User["End user"] --> AppUI["App module UI"]
    AppUI --> Runtime["ForsettiRuntime<br/>silent background"]
    Runtime --> AppModule["ForsettiAppModule"]
    Runtime --> Services["Host services"]

Loading

Use this when the product is a single app. The framework boots silently, activates the app module, and the user interacts with app-owned UI.

Pattern B: Multi-Module Single Application

flowchart TB
    User["End user"] --> UI["Dedicated UI module"]
    Runtime["ForsettiRuntime"] --> UI
    Runtime --> ServiceA["Service module: sync"]
    Runtime --> ServiceB["Service module: telemetry"]
    Runtime --> ServiceC["Service module: export"]
    UI --> Context["ForsettiContext"]
    ServiceA --> Context
    ServiceB --> Context
    ServiceC --> Context

Loading

Use this when the app has one primary UI but several supporting runtime modules. Service modules can run together. UI/app modules can remain enabled together, but the host should present one selected foreground UI for a single-app product.

Pattern C: Developer Testing

flowchart LR
    Developer["Developer"] --> Shell["ForsettiHostRootView<br/>controls visible"]
    Shell --> ModuleList["Service and UI module lists"]
    Shell --> Active["Selected UI module"]
    Shell --> Diagnostics["Errors and action feedback"]

Loading

Use this while building, validating manifests, testing entitlements, and comparing multiple app modules.

Pattern D: Dashboard Deployment

flowchart TD
    User["End user"] --> Dashboard["Dashboard / launcher UI"]
    Dashboard --> AppA["App module A"]
    Dashboard --> AppB["App module B"]
    Dashboard --> AppC["App module C"]
    Dashboard --> SharedServices["Shared service modules"]

Loading

Use this when users intentionally move among multiple separate applications. A dedicated dashboard module is recommended so navigation remains product-owned.

Decision Tree

flowchart TD
    A{"Is this one production app?"}
    A -- yes --> B{"Does it need separate background service modules?"}
    B -- no --> P1["Pattern A"]
    B -- yes --> P2["Pattern B"]
    A -- no --> C{"Is this only for internal testing?"}
    C -- yes --> P3["Pattern C"]
    C -- no --> P4["Pattern D"]

Loading

Production Rules

Rule	Why
Hide developer controls in Pattern A and B production apps.	End users should not see framework administration unless dashboard behavior is intentional.
Keep app UI in app-owned modules.	Product logic and presentation remain outside framework internals.
Use services for shared background behavior.	UI modules stay focused and testable.
Keep manifests bundled and versioned with the app.	Activation policy should be reviewable at build time.