Skip to content
Christian Andrey Reyes

QuickQueue

One queue system, three clients: a Spring Boot API behind a React web app and a native Android app.

QuickQueue

Pitch video in production

Role
Solo developer
Period
Feb – May 2026
Stack
Spring Boot, Java 17, Kotlin, Android views, React, Supabase PostgreSQL, Spring Security, JWT, Google OAuth, Vite, Leaflet, Retrofit, WorkManager, Docker
Links
Live site (opens in a new tab)Repository (opens in a new tab)

The problem

Standing in line at a service office wastes time a phone could give back. QuickQueue lets people find an office on a map, take a ticket, and get notified as their turn comes, while staff and business owners run the queue from the web. The same rules had to hold in the web app and in a native Android app.

What I built

  • A Spring Boot REST API with JWT authentication, Google sign-in, and separate login strategies for users and admins.
  • Queue tickets, service offices and staff modelled with JPA on Supabase PostgreSQL, with business registration and admin approval.
  • A queue event publisher with listeners, so notification channels plug in without changing queue logic.
  • A React web client with a Leaflet map for finding offices and joining queues, plus partner, staff and admin dashboards.
  • A native Android app in Kotlin with XML layouts, activities and fragments, calling the same API through Retrofit.
  • Background polling with WorkManager that raises Android notifications when a ticket is near the front, being served, or complete.
  • Profile and password management on web and mobile, and a Dockerfile for deploying the API.

How it works

  1. 01

    Register

    A business applies for its office and an admin approves it.

  2. 02

    Discover

    Customers find approved offices on a map in the web or Android app.

  3. 03

    Join

    Taking a ticket goes through the API's queue facade.

  4. 04

    Serve

    Staff advance the queue; each change is published as a queue event.

  5. 05

    Notify

    Listeners and the Android background worker turn status changes into notifications.

Decisions

A strategy per login type

User and admin logins accept different accounts and return different data, so each is a separate strategy behind one interface. One login method with inline role checks was the alternative; it would grow a new branch for every role.

Queue events instead of direct calls

Queue changes are published as events, and listeners such as the email and logging listeners react to them. Calling each notifier from the queue service was simpler, but it would tie every new channel to queue code.

Polling on Android instead of push

The Android app checks ticket status with a periodic WorkManager job. Push messages would arrive sooner, but they need a messaging service and device token handling on the API; polling reused the endpoints that already existed.

Evidence

86 commits: 75 under my account, 11 from a university lab workstation
git shortlog -sn HEAD
Android screens built with XML layouts
git ls-files mobile/app/src/main/res/layout
8 unit test classes with 55 tests for models, factories, queue events and the queue service
git grep -c @Test -- backend/src/test/java/com/example/demo/auth backend/src/test/java/com/example/demo/queue backend/src/test/java/com/example/demo/shared
Web client deployed
Live site (opens in a new tab)
Source code
Repository (opens in a new tab)

Next

  • Replace polling with push notifications once the API has a messaging service.
  • Add integration tests for the queue endpoints; the current unit tests cover models, factories, queue events and the service layer.