Repository navigation
Solution Overview
Quack! lets Stevens students pin a spontaneous meetup on a campus map, such as "Studying for CS102!" at the dining hall at 7, so anyone nearby can join.
Meeting people in college means joining clubs, which demand schedules and commitment, or relying on class, which leaves two minutes to talk. Nothing covers the low-commitment middle: four classmates would join that study session if they knew it existed. Group chats only reach friends, stories broadcast without coordinating, and event platforms assume weeks of planning.
Technically it is a location-first mobile application for a single campus, backed by a REST API and a spatial database. A student opens the app to a map of Stevens Institute of Technology, sees what is happening nearby in the next few hours, and either joins a meetup or drops a pin of their own with a time, a category, and one line of detail.
Ship a deployed, tested app that proves the post, discover, and join loop for Stevens students.
Goals
Complete the post, discover, and join loop with real persistence and real accounts
Posting an event takes under 30 seconds of user time: location, time, one line of detail
Discovery is location-first. The map is the home screen
Only students of the target campus can sign in
Deployed with seeded demo data, not a localhost prototype
Architecture a four person team can build, test, and reason about in 14 weeks
Non-goals
Horizontal scale. A single application instance and a single database is sufficient
Real-time push. Polling and refresh on navigation are acceptable
Integration with the university's own identity provider (see 1.6)
Messaging, feeds, payments, ticketing, recurring events, check-in, ratings
Moderation tooling and admin dashboards
Offline support and multi-campus tenancy
There is exactly one class of user: a verified Stevens student, authenticated through their stevens.edu Google Workspace account. No account can be created any other way, and there is no anonymous browsing. Instructors and TAs also use stevens.edu, so the allowlist is a single entry.
Host and attendee are roles a user occupies per event, not account types. The same person hosts one event and attends another. Both are derived from data rather than from a role column, and the resulting permissions are:
There is deliberately no administrator or moderator user, since moderation tooling is out of scope for the semester.
Three tiers: a client that renders the map and every screen, a stateless Spring Boot API that owns logic, authorization, and persistence, and Postgres with PostGIS. The client loads tiles from Mapbox directly; the API talks to Google only during sign-in.
No queues, caches, workers, or microservices. Each adds a failure mode we cannot afford in 14 weeks.
Inside the API, controllers validate and map requests, services own business rules and all authorization, and repositories own queries. Keeping authorization in services means a new controller cannot bypass it.
The API runs as a containerized service on a managed platform, with the database on a managed PostgreSQL host that supports the PostGIS extension. The client is built and distributed separately from the API. Map tiles come directly from Mapbox to the client, so no tile traffic passes through our server. Every managed service is used on a free or near-free tier, because the project has no budget.
Two environments: local, and one deployed environment for staging and the demo. Client and server deploy separately, so OAuth redirect URIs are registered for both.
Map queries return in under 500ms at p95 with 2,000 seeded events. Target scale is 500 users, 2,000 events, and 50 concurrent sessions. Availability is best effort, but the demo build must be live and seeded in week 14.
No passwords stored, HTTPS only, no secrets in the repository. Coordinates are never logged next to a user id. Personal data is limited to email, display name, avatar URL, and provider subject id.