Project overview
Liquid247 Admin is an operations frontend that brings intelligence content, monitoring settings, operational data, and account management into one workspace. Built with React and TypeScript, it uses MSW to simulate business APIs in the browser so that the main workflows can be explored without a backend service.
The current deployment is a Mock demo without connections to real exchanges, account services, or a database. Probes, statistics, and business actions described here use simulated data.
Intelligence workspace and publishing
The intelligence workspace supports section-based search, pagination, editing, saving, publishing, taking content offline, and republishing. Content uses three publication states: published, unpublished, and offline. Super administrators can delete unpublished content or archive content that has previously been published.
The editor includes a title, body, type, token, publication time, schedule, click count, favorite count, and frozen snapshot. Its Tiptap rich-text editor supports headings, bold, italic, underline, strikethrough, lists, blockquotes, links, separators, undo, and redo.
Editor JSON in body_doc is the primary content format, with plain text automatically extracted into body. The frontend preview renders allowed nodes and link protocols, giving editing, storage, and preview a shared content specification.
Scheduled publishing uses a separate scheduled_at field. Content remains unpublished until execution, when the actual publication time is updated. In the demo, requests trigger schedule checks while the application is running, so the page must remain active; this is not an offline server task.
Monitoring and reference data
The admin separates reference data and monitoring features into several modules:
- Glossary: search, create, edit, delete, and manage publication states.
- Monitoring pool: search, enable or disable entries, and run pre-admission probes with simulated success, failure, and timeout results.
- Whale list: maintain addresses, venues, win rates, and 30-day profit and loss; copy original addresses and show the latest related intelligence.
- Data connections: create, edit, probe, and enable or disable sources; market-data credentials are represented only by
secret://references. - Latency checks: inspect node coverage, latency, and status; run periodic or manual simulated probes and configure thresholds and exception policies.
Probe credentials are bound to the instrument and trading pair. Disabling an instrument or data source pauses automatic publication of related scheduled intelligence. Latency exceptions follow the configured policy for stopping automatic publishing.
Operational analytics and permissions
The duty overview applies a shared date range to six metrics, PV/UV trends, registration trends, and content-type distribution. Demo statistics cover the most recent 90 days.
Frontend user management supports search by email, numeric ID, or nickname, along with disabling and restoring accounts, viewing read-only preferences and favorites, and generating a simulated temporary password shown once.
The admin distinguishes super administrators from content administrators. Super administrators create, delete, enable, and disable content administrators and configure access to five sections. Sessions, navigation, routes, and Mock write APIs all check permissions. Disabling or deleting an admin account also clears its simulated session.
Operation logs capture the time, account, role, action, numeric object ID, notes, and before-and-after states so that changes in the demo workflows can be reviewed.
Technology and project structure
| Technology | Purpose |
|---|---|
| React 19, TypeScript 5 | Page components and business types |
| React Router 7 | Admin routing |
| Ant Design 6 | Tables, forms, dialogs, and other admin controls |
| Tiptap 3 | Rich-text editing and content structure |
| Recharts 3, Day.js | Operational charts and date handling |
| MSW 2 | Simulated browser APIs |
| Vite 7 | Development server and static builds |
| Vitest, Playwright | Unit and browser workflow testing tools |
The code is organized by responsibility:
src/app Route layouts, sessions, and permissions
src/features Business pages
src/components Shared pages, tables, filters, states, and rich-text editor
src/content Content specification, plain-text conversion, and safe previews
src/services Request wrappers
src/mocks Seed data, domain rules, and MSW handlers
src/types.ts Business enums and data types
e2e Browser workflow tests
Pages request data through services instead of accessing the simulated repository directly. This separation preserves the calling contracts for a future backend integration.
Demo data and deployment
Simulated data is stored in browser localStorage under liquid247:mock-db:v2, retaining changes after a refresh. The project supports migration from older demo data and provides a reset action to restore the initial state.
MSW's Service Worker requires a secure context such as HTTPS or localhost. Static hosting must serve /mockServiceWorker.js directly and route /admin/* requests back to index.html.
Connecting a real service requires restricting MSW startup to Mock mode and updating the API address. Authentication, auditing, scheduled jobs, password services, and durable storage must be implemented on the server. The current browser simulation demonstrates frontend workflows and engineering decisions.
