In a world obsessed with the newest “push” technologies, Team Bodhi Bytes took a different path for the AIORI-2 Hackathon. Tasked with PS-11 (QR-to-Database Real-Time Interaction), we prioritized reliability and architectural pragmatism. Our project proves that you don’t always need complex, stateful WebSockets to create a “real-time” experience; sometimes, the most robust solution is a perfectly tuned HTTP Polling engine.
1. The Core Interaction: The Physical-to-Digital Bridge
The system solves a classic problem: how do you make a static webpage react instantly when someone scans a physical object across the room? Our solution uses the ISO/IEC 18004 (QR Code) standard as the trigger and a Django/DRF backbone as the brain.
The User Journey:
- Host Side: Generates a unique QR code via the /generate_qr/ portal.
- Attendee Side: Scans the code. Their mobile browser hits a unique URL that updates a MySQL record from pending to completed.
- Dashboard Side: Using a 3-second AJAX Polling loop, the dashboard “sees” the database change and injects the new data into the UI—no refresh required.
2. Architecture: Why We Chose Polling over Push
While the hackathon prompt mentioned RFC 6455 (WebSockets), our team conducted a risk-benefit analysis. WebSockets require stateful servers (ASGI), message brokers (Redis), and complex connection management.
Instead, we validated the power of RFC 9110 (HTTP Semantics). By using standard GET requests on a 3-second interval, we achieved:
- Horizontal Scalability: Our app can run on any standard web server (Gunicorn/NGINX).
- Stateless Reliability: If a connection drops, the next poll simply picks up where it left off.
- Reduced Complexity: We traded a 2-second “latency” for a system that is 10x easier to maintain and audit.
3. Technology Stack & Standards Mapping
We built a modern, 3-tier application where every layer adheres to international standards:
| Layer | Technology | Standard |
|---|---|---|
| Data Interchange | JSON | RFC 8259 |
| Transport | HTTP/1.1 | RFC 9110 |
| API Architecture | Django REST Framework | REST Principles |
| Physical Trigger | QR Code | ISO/IEC 18004 |
4. Implementation: The AJAX Heartbeat
The “magic” of the real-time update happens in a simple, elegant JavaScript loop. By using the modern fetch() API, we query our DRF endpoint and perform a client-side “diff” to see if new scan events have arrived.
JavaScript
// The heartbeat of the system
setInterval(async () => {
const response = await fetch(‘/api/data/’);
const data = await response.json();
updateDashboardUI(data); // Injects new rows into the table
}, 3000);
This ensures the “Live Feed” feel without the overhead of a persistent socket.
5. Lessons Learned & The Road Ahead
Our sprint methodology taught us that “Real-Time” is a spectrum, not a binary. For event check-ins and attendance, a 3-second poll is functionally identical to a sub-second socket push, but significantly more stable.
Future RFC Alignment:
- Security (RFC 7519): Our next sprint involves securing the scan-capture endpoint with JWT (JSON Web Tokens) to ensure that every check-in is a verifiable credential.
- Efficiency: We plan to explore HTTP Long-Polling, a middle-ground that reduces empty requests while staying within the stateless RFC 9110 model.
