The server confirms the bid
Confirmation belongs to the backend and STOMP distributes live events. The broker keeps per-instance state in memory, a limitation of the demonstration scope.
CASE STUDYMOBILE & BACKEND
QuickBid
One auction. Two connected ends.
Project · Collaborative · demo
JavaSpring BootPostgreSQLSQLReact NativeReactTypeScriptWebSocket / STOMPDockerTesting
Overview
Mobile auctions with real-time bids, connecting React Native and a Java backend.
Catalog, consignments, accounts and notifications complete the auction workflow. A collaborative demonstration project with fictional data and simulated payments.
Problem
Keep the mobile experience aligned with bids and deadlines confirmed by the server.
My role
I participated in the collaborative development of the solution. My backend contributions include bid-limit and deadline validation, recent-history restoration and integration tests.
Architecture
React Native/TypeScript → REST and WebSocket/STOMP → Spring Boot services → PostgreSQL. JWT and refresh tokens manage sessions; Flyway maintains the schema. The STOMP broker keeps per-instance state in memory.
Technical decisions
Local drafts, connected bids
Consignment drafts are stored on the device. Bidding requires connectivity and server confirmation to keep the offer aligned with the auction state.
Challenges and solutions
Bidding logic validates auction deadlines and restores recent history. In-memory broker state and local file storage define the limits of the demo.
Outcomes
Integrated backend and mobile client, with server-confirmed bids and real-time events. Payments and commercial data are for demonstration.