The Serverless Community

A. The Ghost Relay (Serverless Leaderboard)

The Challenge: Storing dynamic user data (XP, Ranks) on a static file system and serving it to thousands of users without hitting GitHub's API rate limits or Cloudflare's sub-request limits.

The Workflow

1. Client-Side Cryptography:

   The app generates a signature of the score payload using a shared secret. This prevents tampering during transit, ensuring that a user cannot spoof their own XP ranking.

2. The Gatekeeper (Cloudflare Worker):

   The Worker verifies the cryptographic signature and checks the IP address against a KV store to enforce a strict "1 submission per 24 hours" policy.

3. The Caching Layer (Defeating Limits):
   • The Limit Problem: If every user opening the leaderboard triggered a fresh fetch to raw.githubusercontent.com, GitHub would rate-limit the Worker's IP immediately, and Cloudflare sub-request costs would skyrocket.
   • The Solution: The Cloudflare Worker implements the Cache API to store the leaderboard.json response for 3600 seconds (1 hour).
   • The Mechanics: When a request comes in, the Worker first checks the Edge Cache. If present, it serves the JSON immediately (0ms latency, 0 upstream calls). If missing, it fetches from GitHub, caches it, and serves it.
   • The Impact: This turns 10,000 user requests into just 1 upstream GitHub call per hour per data center. This effectively makes the read operation free and infinitely scalable.
4. Issue-as-Database:

   Instead of opening a traditional database connection (which costs money), we use GitHub Issues as an asynchronous message queue and Write-Ahead Log. The Worker POSTs the data as a new Issue in a private repo.

5. The Cron Processor:

   A GitHub Action wakes up on a schedule, processes the open issues, updates the static leaderboard.json file on the Ghost Branch, and closes the loop.

B. "Issue-Ops" App Submission Pipeline

We believe in "Infrastructure as Code" (IaC) for community engagement. To submit an app to Orion, a developer doesn't fill out a web form that vanishes into a database; they initiate a public workflow.

Our "Submit App" button actually constructs a pre-filled GitHub Issue URL. When the user clicks "Submit", they are creating a public record on our "Requests" repository. This has two benefits:

• Transparency: The entire community can see what apps are pending, who submitted them, and why they were accepted or rejected.
• Automation: The creation of the issue triggers our CI bots immediately, which lint the metadata and start the malware scan before a human moderator even sees the request.

https://github.com/Orion/Store/issues/new?title=New+App&body=...

C. Governance via Labels

Orion manages the lifecycle of thousands of apps without a dashboard UI. We use a strict Label State Machine. The labels applied to a GitHub Issue (the app request) act as control signals for our backend bots.

This system allows us to perform complex administrative actions—like merging data, deploying updates, or banning users—simply by toggling a label on the GitHub mobile app.