Desktop App: Backend & Services

Part 3 of 5 in the Architecture & Foundation series.

This page covers the backend layer for the web version of Ediky: why Firebase for auth and data, why Judge0 self-hosted on Oracle Cloud for code execution, and why Cloudflare for hosting and serverless compute.

Firebase: Serverless Authentication & Real-Time Database

What Firebase Is

Firebase, by Google, is a backend-as-a-service platform — infrastructure that would normally require hiring engineers to manage, bought as a service instead. It provides Authentication (email/password, Google, GitHub sign-in), Firestore (a real-time cloud database), and Cloud Storage.

Why Firebase for Ediky?

Cost: Firebase's free tier absorbs the traffic of an early-stage product with generous free quotas — no need to hire a backend engineer or run servers just for auth and data.

Scale: Firebase scales automatically from a handful of concurrent users to thousands without capacity planning on Ediky's side.

Real-time sync: when a student solves a problem on their phone, Firestore updates, and any other device with that document open — a laptop, also logged in — sees the change via a listener within moments. No polling, no manual refresh.

Built-in security: Firestore's security rules ("user 123 can only read/write their own documents") are enforced server-side and can't be bypassed from the client.

Authentication Flow

diagram100%

rendering diagram…

drag to pan · ctrl / ⌘ + scroll to zoom

A JWT (JSON Web Token) is a cryptographically signed string proving "this user is logged in" — the browser carries it and presents it as proof of identity on every request.

Firestore Data Model

Collection: users
  Document: user_123
    Fields:
      - email: "student@nit.edu"
      - problems_solved: 47
      - last_login: 2026-07-14T10:00:00Z

Collection: submissions
  Document: submission_456
    Fields:
      - user_id: "user_123"
      - problem_id: "problem_789"
      - code: "vector<int> twoSum(...) { ... }"
      - language: "cpp"
      - status: "Accepted"
      - timestamp: 2026-07-14T09:45:00Z

Simple, JSON-like, flexible.

Oracle Cloud Free Tier: Hosting Judge0

What Judge0 Does

Judge0 is a code execution engine. Given code, a language, and input, it compiles the code, runs it, and returns output, execution time, and memory used.

Why Self-Hosted on Oracle Cloud?

Three alternatives were weighed:

• A closed judge like LeetCode's — can't be extended or run against Ediky's own problem set.
• Judge0 as paid SaaS — roughly $0.01 per submission; at 1,000 students × 600 problems, that's 600,000 submissions and around $6,000/month, unsustainable for a free platform.
• Self-hosted on Oracle Cloud Free Tier (Ediky's choice) — 2 vCPUs, 12 GB RAM, 100 GB storage, free indefinitely rather than for a trial period, run as a Judge0 Docker container. Cost: $0/month. Trade-off: no uptime SLA.

For a beta platform, that trade-off makes sense.

Execution Flow

diagram100%

rendering diagram…

drag to pan · ctrl / ⌘ + scroll to zoom

It scales from zero to thousands of submissions a day, which is sufficient for Ediky's beta. When it grows past that, the path is either paid Oracle capacity or sharding Judge0 across multiple instances.

Cloudflare Pages & Workers: Global Web Hosting

The Problem Cloudflare Solves

Without a CDN, a student in Tokyo requesting a server in the US pays roughly 340ms round-trip. Cloudflare runs 200+ data centers worldwide, so that same request is handled by a nearby edge server in a few milliseconds instead.

Two Cloudflare Products

Cloudflare Pages hosts static files — the React build output. On deploy, Cloudflare copies files to all edge servers, so a student in Tokyo and a student in São Paulo both get served locally with zero downtime.

Cloudflare Workers run serverless functions at each edge. A student in Tokyo submitting code hits the Tokyo Worker, which calls Judge0 in Oracle USA over Cloudflare's optimized internal routing rather than the public internet, and returns the result back through the same nearby edge.

Architecture

diagram100%

rendering diagram…

drag to pan · ctrl / ⌘ + scroll to zoom

Worker Example: Code Proxy

// Cloudflare Worker (runs at edge, near user)
export default async function handle(request) {
  const data = await request.json();

  // Validate code size
  if (data.code.length > 100000) {
    return new Response("Code too long", { status: 400 });
  }

  // Forward to Judge0 in Oracle (optimized routing)
  const response = await fetch("https://judge0.ediky.com/api/submissions", {
    method: "POST",
    headers: { "Authorization": `Bearer ${JUDGE0_TOKEN}` },
    body: JSON.stringify({
      source_code: data.code,
      language_id: data.language,
      stdin: data.stdin
    })
  });

  // Log to Firebase
  const result = await response.json();
  await logToFirebase(data.user_id, result);

  // Return to user (already at edge, close by)
  return new Response(JSON.stringify(result));
}

How They Connect

1. Student signs in → Firebase Auth issues a JWT.
2. Student solves a problem → React sends to the nearby Cloudflare Worker.
3. Worker forwards to Judge0 → Oracle compiles and runs the code.
4. Results return → Worker logs the submission to Firestore.
5. Real-time sync → Firestore notifies all other devices instantly.

All pieces work together, and none of them requires Ediky to run or patch its own server.

---

← Previous: Frontend Architecture→ Next: Desktop Features & Data Flows↩ Overview: Architecture & Foundation