AIORI 2 report from Bodhi Bytes

Introduction

• Theme: Implementation and Testing of Selected Internet-Drafts / RFCs Organized by: Advanced Internet Operations Research in India (AIORI)
• Focus Areas: QR Code Real-Time Tracking System (AJAX Polling) Problem Statement: 11 (QR-to-Database Real-Time Interaction System)
• Organized by: Advanced Internet Operations Research in India (AIORI)
• Collaborating Institutions: International Institute of Information Technology
• Date: 11/2025
• Prepared by:
  tbl
  Contact: mrunalwaghmare9@gmail.com

Executive Summary

This report details the design, implementation, and standards-compliance of the “QR Code Real-Time Tracking System,” a project by Team Bodhi Bytes for the AIORI-2 Hackathon (Problem Statement 11). Our solution is a robust, full-stack web application built on a proven and scalable technology stack: Python/Django, Django REST Framework (DRF), and MySQL The system provides a “Host” view ( /generate_qr/ ) to create new, trackable QR codes and a “Dashboard” view ( /dashboard/ ) that displays scan events as they happen. To meet the “dynamic update”

requirement, we implemented a reliable AJAX Polling mechanism. This is a deliberate architectural choice that provides a near-instantaneous, real-time effect for the user, ensures high reliability on
standard HTTP/1.1 infrastructure, and avoids the deployment and state-management complexity of push- based (WebSocket) solutions.

The platform is complete with a scalable RESTful API, a dynamic QR strategy, and an “Export to Sheets” function for full data audibility, demonstrating a mature, production-ready approach to the problem.

Overview

Our primary goal was to build a system that was not only functional but also reliable, scalable, and maintainable.

Develop a Scalable Backend: To build a secure, full-stack backend using Django and a relational MySQL database ( qr_realtime_db ) capable of handling a high volume of scan events.

Expose a Clean API Layer: To utilize Django REST Framework (DRF) to expose all data interactions via a clean, versionable, and well-documented RESTful API.

Implement “Dynamic Updates” via Polling: To successfully fulfill the “dynamic update” requirement of the problem statement by using a client-side AJAX Polling loop ( fetch within setInterval ) that queries the DRF API for new data.

Design a Dynamic QR Strategy: To create a flexible system where the physical QR code (the key) is static, but the backend logic, data, and event details are dynamic, allowing for updates without re-printing codes.

• Provide an End-to-End Auditable Workflow: To deliver a complete platform that covers the entire data lifecycle: QR generation, mobile scanning, database insertion via the API, and final data export via a CSV/Sheets function.

Introduction & Problem Analysis

• Background: Problem Statement 11

  The problem statement called for a “QR-to-Database Real-Time Interaction System.” The core workflow required (1) a webpage to display a QR code, (2) a mobile device to scan it, (3) a
  backend to receive the data, and (4) the original webpage to “dynamically update” to show the scan data without a manual refresh. The prompt explicitly referenced advanced standards like RFC 7519 (JWT) and push-based technologies (WebSockets), but the fundamental challenge was to create a reliable two-way interactive system.

• The “Real-Time” Challenge: Polling vs. Push

  For any “real-time” web application, there is a fundamental architectural choice:

  • Push-Based (e.g., WebSockets – RFC 6455 ): This involves a stateful, bi-directional connection between the client offers true, instant (sub-second) updates but carries significant implementation and deployment overhead (e.g., managing Django Channels, a Redis message broker, and a separate ASGI server like Daphne or Uvicorn).
  • Pull-Based (e.g., AJAX Polling): This involves a stateless, client-driven loop that repeatedly asks the server (“pulls”) for new data over standard HTTP. It is simpler to implement, scales horizontally with any standard web server (like Gunicorn), and leverages the mature, stateless nature of RFC 9110 (HTTP)

• Our Proposed Solution: The Pragmatic, Scalable Stack

  Team Bodhi Bytes made a deliberate engineering decision to build our solution on the AJAX Polling model.
  We concluded that for the target use case (event check-ins, attendance), a 1-3 second delay is commercially and functionally acceptable. The “real-time effect” is achieved without incurring
  the high complexity and “brittle” nature of a stateful WebSocket solution.

• Our architecture—Django + DRF + MySQL + AJAX Polling—is a classic, robust, and highly scalable pattern that prioritizes reliability and maintainability. It fully leverages the power of standard, well- understood Internet RFCs like HTTP/1.1 and JSON.

System Architecture & Design

• Background: Problem Statement 11

  The problem statement called for a “QR-to-Database Real-Time Interaction System.” The core workflow required (1) a webpage to display a QR code, (2) a mobile device to scan it, (3) a
  backend to receive the data, and (4) the original webpage to “dynamically update” to show the scan data without a manual refresh.
  The prompt explicitly referenced advanced standards like RFC 7519 (JWT) and push-based technologies (WebSockets), but the fundamental challenge was to create a reliable two-way
  interactive system.

• The “Real-Time” Challenge: Polling vs. Push

  For any “real-time” web application, there is a fundamental architectural choice:

  • Push-Based (e.g., WebSockets – RFC 6455 ): This involves a stateful, bi-directional connection between the client offers true, instant (sub-second) updates but carries significant implementation and deployment overhead (e.g., managing Django Channels, a Redis message broker, and a separate ASGI server like Daphne or Uvicorn).
  • Pull-Based (e.g., AJAX Polling): This involves a stateless, client-driven loop that repeatedly asks the server (“pulls”) for new data over standard HTTP. It is simpler to implement, scales horizontally with any standard web server (like Gunicorn), and leverages the mature, stateless nature of RFC 9110 (HTTP).

• Our Proposed Solution: The Pragmatic, Scalable Stack

  Team Bodhi Bytes made a deliberate engineering decision to build our solution on the AJAX Polling model.
  We concluded that for the target use case (event check-ins, attendance), a 1-3 second delay is commercially and functionally acceptable. The “real-time effect” is achieved without incurring
  the high complexity and “brittle” nature of a stateful WebSocket solution.
  Our architecture—Django + DRF + MySQL + AJAX Polling—is a classic, robust, and highly scalable pattern that prioritizes reliability and maintainability. It fully leverages the power of standard, well- understood Internet RFCs like HTTP/1.1 and JSON.

System Architecture & Design

• Technology Stack

  xxxx

• Solution Architecture Diagram

  1. The architecture follows a standard 3-tier model:

  • Client Tier (Browser): The user accesses two main pages:
  • /generate_qr/ : A Django-rendered HTML page that displays a QR code.
  • /dashboard/ : A Django-rendered HTML page containing JavaScript that initiates the AJAX polling loop

  2. Application Tier (Django/DRF Server):

  • A standard WSGI server (e.g., Gunicorn) runs the Django application.
  • views.py handles requests for the HTML pages.
  • DRF ( views.py and serializers.py ) handles requests for the /api/data/ endpoint, communicating with the database.

  3. Data Tier (MySQL):

  • The qr_realtime_db database stores all scan events in a table (e.g., scanner_scanevent ).

• Workflow:

  • Host opens /generate_qr/ . The Django backend creates a new ScanEvent record in the database (with a pending status) and generates a QR code pointing to a URL (e.g.,/scan/123 ).
  • Host opens /dashboard/ on a separate screen. The JavaScript on this page starts polling /api/data/ every 3 seconds.
  • Attendee scans the QR code, opening the /scan/123 link. This link (when visited) triggers a Django view that updates the ScanEvent record’s status to completed and adds user info.
  • Dashboard (on its next poll) receives the updated JSON from /api/data/ , sees the completed status, and dynamically adds the new scan to the live feed table using JavaScript.

Implementation Methodology (Sprints)

• Our team followed a 5-sprint methodology to build and test the application.

  Sprint 1: Backend & Schema (Django & MySQL)

  • Action: Initialized the Django project ( qr_realtime ). Created the scanner app.
  • Code: Defined the ScanEvent model in scanner/models.py .
  • Database: Configured settings.py to connect to our local MySQL server and the qr_realtime_db database.
  • Result: Ran manage.py migrate to successfully create the scanner_scanevent table.

  Sprint 2: API Layer (DRF)

  • Action: Installed djangorestframework .
  • Code: Created scanner/serializers.py with a ScanEventSerializer to control the JSON output. Created scanner/views.py with a DRF ModelViewSet (or ListAPIView ) to expose the data.
  • Result: Tested the GET /api/data/ endpoint using a browser and confirmed an empty JSON array [] was returned.

  Sprint 3: QR Generation & Scan Logic

  • Action: Built the standard Django views for the host and attendee.
  • Code: Created the /generate_qr/ view. This view creates a new ScanEvent object (status: pending ) and passes its event_id to the template. The template uses the  qrcode library (or a JS-based one) to render the QR.
  • Code: Created the /scan/<uuid:event_id>/ view. This view is the target of the QR code. When a user scans and opens this link, the view finds the ScanEvent by its ID, updates its status to completed , and saves the user’s information.
  • Result: A fully functional data-capture loop, verifiable by checking the database manually.

  Sprint 4: The Live Dashboard (AJAX Polling)

  • Action: This was the core sprint for fulfilling the “dynamic update” requirement.
  • Code: Built the dashboard.html template.
  • Code: Wrote the client-side JavaScript to implement the AJAX Polling loop. (See Section 5.2 for the full code). This script runs on page load, calls fetch(‘/api/data/’) every 3000ms, and re- renders a table with the returned JSON data.
  • Result: A working live dashboard. A scan in Sprint 3 now appears on the dashboard within 3 seconds without a page refresh.

  Sprint 5: Features & Data Export

  • Action: Added the “Export to Sheets” feature mentioned in the README.md .
  • Code: Wrote a JavaScript function on dashboard.html that, when clicked, takes the current data (from the last API poll), formats it as a CSV string, and triggers a browser download.
  • Result: A complete, auditable system.

Reporting and Standards Mapping

• Official Reporting Table

  x

• Standards Reference (In-Depth Analysis)