How I Built AirQuiz an Offline-First Exam Server (Python/React) to Beat Bad Wi-Fi

#webdev #programming #teaching #productivity

Author: Salah Eddine Medkour

Introduction

My name is Salah Eddine Medkour. I am a Technical Lab Instructor and Network Engineer in Annaba, Algeria. When the internet infrastructure failed in the labs I manage during my final university exams, I engineered AirQuiz, a local-area network (LAN) assessment platform that operates with zero external connectivity.

The Problem

I teach a Master’s level Python course. The internet stability here is unpredictable. During a final exam setup for 45 students, the campus ISP dropped completely. I realized that a standard "cloud-first" deployment to Vercel or AWS was a single point of failure. I needed a system that ran entirely on local hardware.

The Hardware Setup

I had zero budget for enterprise servers. I repurposed my personal equipment to build a dedicated local node.

The Server: I used my ThinkPad. The NVMe storage was the most critical component here (Not a necessity). SQLite writes are file-based, so fast disk I/O was necessary to prevent database locking during simultaneous submissions.
The Network: I utilized a spare router isolated from the campus network. I configured a static IP for the ThinkPad and enabled a strict DHCP pool for the student devices. I physically disconnected the WAN cable to ensure the network was air-gapped and free from external interference.

The Stack: Python (FastAPI) and React

I prioritized low overhead and high concurrency over ease of development.

Backend: I chose FastAPI over Django. The primary reason was asynchronous request handling. When 45 clients send a POST request at the exact same second, a synchronous server often blocks threads. FastAPI uses an ASGI server (Uvicorn) to handle these concurrent connections without latency.
Frontend: I used React. The application loads once on the client device. After the initial load, the network traffic consists only of tiny JSON payloads. This reduces the load on the router significantly compared to server-side rendering.

The Logic

The biggest technical risk was data integrity during the "submit" event. Here is how the backend handles potential race conditions or duplicate submissions:

@app.post("/submit-exam/")
async def submit_exam(submission: schemas.ExamSubmission, db: Session = Depends(get_db)):
    # 1. Check for existing submission to prevent duplicates
    existing = db.query(models.Submission).filter(
        models.Submission.student_id == submission.student_id
    ).first()

    if existing:
        return {"status": "already_received"}

    # 2. Calculate score in-memory
    score = calculate_score(submission.answers)

    # 3. Commit to SQLite with low I/O overhead
    db.add(models.Submission(student_id=submission.student_id, score=score))
    db.commit()

    return {"status": "success", "score": score}

The Results

We successfully deployed AirQuiz for +180 students across four separate exam sessions.

Uptime: 100%. The system remained stable even when the building's internet cut out twice.
Latency: Consistently under 10ms due to the local loopback architecture.
Efficiency: The auto-grading feature reduced administrative work from days to seconds.

Conclusion

This project reinforced that understanding network fundamentals is just as important as knowing modern cloud frameworks. By respecting the constraints of the environment and utilizing local LAN architecture, I ensured a fair and stable exam environment for my students.

AirQuiz on Github