Skip to main content
Darpan’s frontend is the user control surface for the backend engine; these decisions explain where the browser surface ends and backend ownership begins. The app is implemented in drpn-ai/darpan-ui. It helps users set up connections, define schemas and RuleSets, start reconciliation runs, and reopen saved output without moving that work into the browser. The current PWA direction is about shell behavior, route structure, keyboard access, responsive layout, and durable browser workflows. It is not currently an offline-first or installable app.

​
What PWA means today

The frontend does not currently ship a service worker, install prompt, manifest-driven install flow, background sync, or offline reconciliation mode. Those capabilities become documentation topics when they are implemented.

​
Surface model

Darpan pages are split into three surface types. Static surfaces are where users inspect durable state. Workflow surfaces are where users make a focused change or start a run. The route metadata contract keeps those surfaces visible to the shell, tests, and shared styling.

​
Command-first navigation

Darpan avoids assuming a permanent left sidebar or nested application menu. Users start from Ask Darpan, search for the destination, and land directly on the right surface. This matters because the product has several setup records and run-review surfaces. The command model keeps the user focused on intent: open a saved schema, edit an SFTP server, create a run, or review generated output. The command palette is still part of the frontend shell. It routes users to app surfaces while backend search, authorization, reconciliation logic, and output filtering remain service-owned.

​
Workflow posture

Workflow pages are built to reduce setup ambiguity.
  • Create flows prefer one question per step.
  • Edit flows can use compact single-page layouts when the record already exists.
  • Shared controls own common actions such as save, cancel, selection, inline validation, and shortcut choice cards.
  • Plain Esc can abort an active workflow back to its static origin when one is available.
  • Route state preserves the origin label and path so workflow exits feel tied to where the user started.
This model keeps workflow pages smaller and keeps long-lived records on static surfaces.

​
Frontend and backend boundary

The frontend stays thin around durable business behavior. It collects user intent, shows saved records, manages browser interactions, and calls JSON-RPC facade services. Tenant filtering, reconciliation rules, output path logic, and service-side validation remain backend-owned. Backend-owned behavior belongs in the Darpan Moqui component. Frontend code consumes those contracts through typed API helpers and presents the result through shared page surfaces.

​
Future PWA layer

Installability and offline behavior can be added later within the current shell model:
  • Add a manifest only when install behavior is intentional and tested.
  • Add a service worker only with clear cache invalidation and session handling.
  • Treat offline UI as a product state, not a silent network failure.
  • Keep reconciliation execution and generated-output durability on the backend.
  • Document which surfaces work without a network before calling the app offline-ready.
Until then, Darpan is a responsive browser app with PWA-oriented shell patterns, not a fully offline PWA. See also: Frontend design system for shared CSS, component, and page-surface contracts; Engineering process for how frontend changes are traced and verified.