Architecture

This page describes the internal architecture of the Yanshan Meeting Big Data System — how its components are structured, how they communicate, and why they are arranged the way they are. Understanding this architecture helps you reason about API request paths, deployment constraints, and the boundaries of the system when integrating or troubleshooting.

The system is composed of four tightly integrated components, all shipped inside the portable ZIP package.

启动系统.bat

Type: CLI / Launch Script

启动系统.bat is the entry point for the entire system. Double-clicking it starts the application server by invoking the bundled node.exe runtime. You do not need to open a terminal or pass any arguments — the script encapsulates all startup logic. If the server is not running, no HTTP requests can be served.

Bundled node.exe

Type: Runtime Library

node.exe is the JavaScript runtime engine included directly in the portable package. It powers the Web Application Server without requiring you to install Node.js, npm, or pnpm on the host machine. From your perspective as an API consumer, this component is invisible — it operates beneath the server layer and requires no configuration.

Web Application Server

Type: Service

The Web Application Server is the HTTP service that listens on port 3005. It serves two things: the browser-based meeting management interface (UI assets) and the routes that delegate to the API Layer. Any device on the same local network can reach this server at http://<secretary-computer-IP>:3005. This is the component you target with all HTTP requests.

API Layer

Type: API

The API Layer sits behind the Web Application Server and handles all data-oriented HTTP requests — translating browser actions and programmatic calls into business logic operations and data storage interactions. It is the interface you interact with when making structured requests to read or write meeting data. All request/response exchanges follow HTTP conventions over port 3005.

The following trace follows a complete request cycle, from launching the system to receiving an API response.

1. Launch — The secretary (书记员) double-clicks 启动系统.bat on the Windows 10 host machine. The batch script invokes Bundled node.exe, which in turn starts the Web Application Server on port 3005.

2. Local access — A browser on the secretary's machine navigates to http://localhost:3005. The Web Application Server receives the connection and serves the meeting management UI.

3. LAN access — A browser on any other device connected to the same local area network navigates to http://<secretary-computer-IP>:3005. The server handles this request identically to a local request; no additional configuration is needed.

4. User interaction triggers an API call — The browser UI sends an HTTP request (e.g., to load meeting records or submit data). The Web Application Server receives the request on port 3005 and routes it to the API Layer.

5. API Layer processes the request — The API Layer executes the relevant business logic, reads from or writes to the back-end data store, and constructs a response.

6. Response returned to the browser — The API Layer returns the response to the Web Application Server, which forwards it over HTTP back to the requesting browser. The UI updates accordingly.

Control flows strictly in one direction through the stack: 启动系统.bat → node.exe → Web Application Server → API Layer → data store, with responses traveling back up the same path.

Single-file launch via 启动系统.bat

Rather than requiring the operator to open a terminal, set environment variables, or remember CLI commands, the entire startup sequence is encapsulated in a double-clickable batch file. This reduces the technical burden on the secretary and eliminates a class of human errors during deployment in meeting environments.

Bundled node.exe instead of a system-installed runtime

Shipping node.exe inside the portable package means the host machine never needs Node.js, npm, or pnpm installed. This was a deliberate trade-off: it increases the ZIP archive size but eliminates all runtime dependency management. In low-IT environments — such as meeting rooms or government offices — this is the correct trade-off because environment consistency matters more than package size.

Fixed port 3005

Port 3005 is hardcoded into the deployment. This simplifies both documentation and firewall rules: you always know which port to allow or block. The trade-off is that if another process already occupies port 3005 on the host machine, the server will fail to start. In practice, 3005 is not a well-known reserved port, so collisions are rare in typical meeting environments.

Local network (LAN) accessibility by default

The Web Application Server binds in a way that makes it reachable from other devices on the same LAN using the secretary's machine IP. This enables meeting participants or administrators to access the system from their own devices without any additional configuration, which is the primary multi-device use case this system is designed for.

Known limitations

• Port collision risk — Because port 3005 is fixed, any other service already bound to that port on the secretary's machine will prevent the server from starting. There is no built-in port fallback or conflict resolution.
• Windows 10 only — The portable package and 启动系统.bat are designed exclusively for Windows 10. The system cannot be deployed on macOS, Linux, or other Windows versions without modification.
• No authentication at the network layer — LAN access is open by default. Any device on the same network that knows the IP address and port can reach the application. Access control is the responsibility of the network environment (e.g., a private meeting-room LAN), not the application itself.
• Single-host deployment — The entire stack — runtime, server, API layer, and data storage — runs on one machine. There is no built-in support for distributed or high-availability deployments.

Alternatives not chosen

• Requiring system-installed Node.js — Rejected because it would require IT involvement on each secretary's machine and introduces version-mismatch risk.
• A packaged executable (e.g., via pkg or Electron) — Would have produced a single .exe but would have complicated server-side debugging and updates. The current approach keeps the runtime and application code separately visible inside the extracted directory.
• A containerized deployment (e.g., Docker) — Rejected for the target audience: Docker requires installation, familiarity with container concepts, and is not appropriate for operators with limited technical expertise.

When to use a different approach

If your deployment requires concurrent access by a large number of users, persistent high-availability, or centralized authentication, this portable package is not the right fit. In those scenarios, consider a server-hosted deployment of the application with a dedicated Node.js environment, a reverse proxy, and appropriate authentication middleware.