AreUComing

Hackathon Project / WaffleStudio Wackathon 2026

Role / Backend development, session domain design, REST API, real-time location history flow

Tech / Java, Spring Boot, React, WebSocket, Docker, MySQL, GitHub

Links / Backend / Frontend / Figma

AreUComing is a location-based mobile web app where partners can share the process of moving toward a meeting place, and keep that process as a record after they meet.

I designed the session domain from location-sharing request, acceptance, progress, to completion, and implemented REST APIs and backend/frontend WebSocket communication. Coordinates, memos, photos, and meeting-complete events created during the trip are stored in one history model, so they can be used both for real-time map display and later history lookup.

The project was built at WaffleStudio Wackathon 2026 and won 3rd place.

• Designed the overall DB schema, including sessions and location point history.
• Modeled a location-sharing request as a session with PENDING / ACTIVE / DONE states.
• Implemented REST APIs for session creation, current session lookup, status lookup, acceptance, completion, photo upload, and history lookup.
• Implemented the backend WebSocket handler, processing location coordinates, memos, and meeting-confirmation events based on session state and user permission.
• Implemented the frontend flow for WebSocket connection, periodic location sending, receiving the partner's location, and updating map markers and routes.
• Loaded existing history through HTTP and received new coordinates through WebSocket, so the map state could be restored even after refresh.

The first thing I had to organize was treating location sharing not as simple coordinate transfer, but as a stateful session. When a user requests location sharing, the session becomes PENDING. When the partner accepts it, it becomes ACTIVE. After meeting completion or cancellation, it ends as DONE.

The session was shared by a couple, not by a single user, so access control was also necessary. I compared the current user's couple information with the session's coupleId, and blocked access when they did not match. To prevent multiple PENDING/ACTIVE sessions for the same couple, the server returned the existing session instead of creating a duplicate.

I also did not manage coordinates, memos, photos, and meeting-complete events as separate pieces. I integrated them into a common history model called SessionPoint. With one storage structure, real-time map display, refresh recovery, and post-session history lookup could run on the same data flow.

Mobile screens for checking real-time routes and session state.