Skip to content

CCS Frontend Redesign & Backend Upgrade

redsh4de requested to merge redsh4de/ccs-proposals:redsh4de-ccs-redesign into master

What this proposal is about

This proposal aims to replace the CSS frontend with a newer design, and the backend with a new system built on Astro and Deno. The current infra has served the community well, but carries significant technical debt.

Why a rewrite if the current system works? Is this fixing what's not broken?

  • Architecture: The current system requires three separate services (PHP, Ruby, MySQL) and rebuilds the entire static site every minute regardless of whether anything changed. The new system would be a single Astro + Deno process with an embedded SQLite database, which would process proposal changes via webhook events (with a fallback to polling if webhooks are not available).

  • Maintenance: The current codebase depends on abandoned or deprecated packages (Laravel 5.7 and PHP 7 reached end-of-life in 2019). The new codebase would use a single runtime with minimal dependencies.

  • UI Design: With the new getmonero.org site soon live, the CCS page needs a UX refresh in any case. The original intention was to only update the frontend, but given the technical debt outlined above, a backend replacement is a natural extension of the work.

What technologies would be used?

  • Astro: Renders pages to static HTML by default and ships zero client-side JavaScript. The new getmonero.org site is also built in Astro, so the CCS and main site would follow the same patterns, easily share UI components and design language, making it easier for contributors to work across both.

  • Deno: A security-oriented JavaScript runtime built on Rust. In contrast to Node.js, Deno has a built-in permission system that denies all outside access by default, and only allows what is explicitly granted. Sounds familiar? ;)

  • SQLite: Replaces MySQL as the database. The CCS is a single-server, low-write workload - there is no need for a separate database server. It runs embedded in the application, is backed up by copying a single file, and eliminates an entire service from the stack.

What will be accomplished

Milestone 1: New frontend on existing backend (19 XMR)

Deliver a version of the new Astro frontend which uses the existing Laravel backend as the data source, with some new routes and UX improvements. No backend changes yet.

  • Full page re-implementation in Astro, following the design language of the new getmonero.org site
  • Still no client-side JavaScript
  • Proposal explorer with server-side filtering, sorting, and search
  • Proposal detail and donation pages consuming the existing Laravel API

Preview of some in-progress work: Index page Explorer Selected Tabs

Estimated completion: ~4 weeks from funding

Milestone 2: Database and backend migration (43 XMR)

Start working on replacing the backend. All data moves from MySQL to SQLite, all processing moves from PHP cron jobs to Deno.

  • MySQL -> SQLite migration scripts
  • Typed interface to monero-wallet-rpc for subaddress generation, deposit scanning, and confirmation tracking
  • GitLab webhook replacing the polling cron, with a fallback to polling if not defined
  • Dockerfile for ease of deployment

Estimated completion: ~9 weeks after Milestone 1

Milestone 3: Final touches (15 XMR)

Polish, testing, and handover of the complete system.

  • End-to-end testing of the full donation flow
  • Setup scripts and documentation for deploying the instance
  • CI pipeline
  • Handover to the current CCS maintainers
  • Address community review feedback

Estimated completion: ~3 weeks after Milestone 2

Who will complete the proposal

redsh4de - full-stack developer. Previous CCS:

This project will be developed in collaboration with SyntheticBird45, who will leverage their experience with their planned CCS redesign project.

Why it is important for Monero and the community

The CCS is how the Monero community funds its development - its a criticial piece of infrastructure. Ergo, it should be up to date, maintainable, with a security-oriented architecture.

More up to date frontend design and eye candy aside, the current system runs on outdated dependencies, uses a inefficient design, and requires three separate services to operate. The new system would ship no JavaScript to browsers, run in a single runtime with explicit permissions, and reduces the infrastructure to one process, while improving both developer and user experience.

The phased approach ensures the community sees results from the frontend part of the proposal ASAP, while the backend work continues behind the scenes.

Funding

32 hours per week at $50/hr for 16 weeks (512 hours total). At ~$330/XMR:

M1: 19 XMR
M2: 43 XMR
M3: 15 XMR

Total: 77 XMR across ~16 weeks.

Merge request reports