Local Server (Deno.serve)
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
In the OpenHWP architecture, Deno.serve() acts as the core delivery mechanism for the application's user interface. Since OpenHWP is designed as a thin desktop shell using deno desktop, it utilizes a local web server to serve the content that is displayed within the native window's webview. This approach allows the application to leverage modern web standards and APIs while maintaining a native desktop presence.
The local server ensures that the application runs within a "secure context" (specifically localhost), which is a prerequisite for utilizing advanced browser features such as the File System Access API. By serving the application locally, OpenHWP bridges the gap between the Deno runtime and the Chromium-based rendering backend (CEF).
Sources: README.en.md:12-14, README.md:15-17
Architecture and Data Flow
The local server is the intermediary between the Deno backend and the webview-based frontend. The desktop shell initializes the native window and points its webview to the address managed by Deno.serve().
Request Lifecycle
- The Desktop Shell initiates a native window using
deno desktop. - The Webview (using the Chromium Embedded Framework backend) requests the application entry point from
localhost. - Deno.serve() intercepts these requests and returns the necessary HTML, JavaScript (including WASM-based engine modules), and assets.
- The Webview renders the content, enabling the user to interact with HWP/HWPX documents.
The diagram shows how Deno.serve() provides the application code to the webview, which then uses browser APIs for local file operations.
Sources: README.en.md:12-16, README.md:15-19
Secure Context and API Integration
A primary reason for using Deno.serve() is to establish a secure context on localhost. This is critical for the application's functionality, as it relies on the File System Access API to handle .hwp and .hwpx files without needing custom native file picker bindings in the Deno layer.
| Component | Role in Local Server Context |
|---|---|
| Secure Context | Established via localhost, enabling modern Web APIs. |
| Chromium (CEF) | The rendering backend that consumes the served content. |
| rhwp (WASM) | The document engine loaded as npm packages via the server. |
| File System Access | Standard API used by the frontend to read/write bytes. |
Sources: README.en.md:12-28, README.md:15-32
Dependency and Toolchain Management
The local server and the broader application run on a single Deno toolchain (version ≥ 2.9.0). Environment setup and dependency caching are managed through Deno's built-in tasks, which prepare the environment for Deno.serve() to function correctly.
This sequence illustrates the developer workflow to initialize the environment and start the local server.
Sources: CONTRIBUTING.md:11-15, orca.yaml:14-18, README.en.md:46-48
Implementation Status
Currently, the project is in an early "scaffold" stage. While the architectural decision to use Deno.serve() is defined in the documentation, the specific application code (such as the main.ts entry point that would call Deno.serve()) is noted as pending in the current roadmap.
- Current State: Project scaffold and documentation only.
- Pending Implementation:
deno.jsondesktop block andmain.tsserver logic. - Target Backend: Chromium (CEF) via the
--backend cefflag.
Sources: README.en.md:8-10, README.en.md:44-46, SECURITY.md:4-8
Summary
The Deno.serve() local server is the backbone of the OpenHWP desktop experience. It transforms the Deno runtime into a provider for a Chromium-based frontend, ensuring a consistent rendering environment across macOS, Windows, and Linux. By providing a secure context, it allows the document engine (rhwp) and the UI to perform high-performance document operations using standard web technologies.