Nurses Now

Nurses Now is a healthcare-sector mediator platform that connects providers and attendees, supporting the operational workflows a healthcare staffing business runs on day to day: scheduling, live provider tracking, attendee management, and in-app communication.

As a Senior Software Engineer / Frontend Engineer, I owned significant frontend features end-to-end, from architecture decisions to implementation, with a particular focus on the real-time tracking and messaging surfaces of the product.

The platform needed to show live provider location on a map, keep that data in sync with the rest of the application state, and layer in-app chat on top, all inside a production application already carrying complex scheduling and attendee-management workflows.

• Real-time data (GPS location updates arriving continuously)
• Multiple simultaneous application states (scheduling, tracking, messaging)
• Reusability across different workflow screens
• Private production environment with limited room for regressions

I treated real-time location data as a separate concern from the rest of the application's server state, subscribing to WebSocket updates and funneling them through a predictable state layer rather than letting live data mutate UI state directly. This kept the map, the list views, and the chat surfaces all reading from the same source of truth.

Location updates flow from the provider's device through a WebSocket connection into the application's state layer, which the map UI and related views subscribe to. REST APIs handle everything that isn't inherently real-time: scheduling, attendee records, and message history.

• Redux Toolkit for real-time/live state that needed predictable updates across views
• TanStack Query for server state (attendee records, scheduling data) to avoid re-fetching and manual cache logic
• Componentized map and chat surfaces so they could be reused across different workflow screens

• Built the live map tracking UI consuming WebSocket-driven location updates
• Implemented in-app chat with its own message state, decoupled from the tracking layer
• Integrated REST APIs for scheduling and attendee-management workflows
• Established reusable frontend patterns adopted across other feature areas of the product

Keeping live map state and cached server state from fighting each other

The hardest part of this feature wasn't drawing a map. It was making sure fast-moving WebSocket location updates didn't collide with the slower-moving, cached server state used for everything else on the same screen (attendee details, schedules). I kept live location in its own slice of state, updated directly from the socket connection, while everything cacheable stayed in TanStack Query. The map component read from both sources but never conflated them, which meant a dropped or delayed socket message never left stale scheduling data on screen, and a stale query cache never delayed a location update.

• Provider tracking became a reliable, always-current part of the operational workflow rather than a source of support tickets
• The reusable map and chat components reduced the effort needed to add similar real-time surfaces elsewhere in the product

• React
• Next.js
• TypeScript
• Redux Toolkit
• TanStack Query
• REST APIs
• WebSocket

Separating real-time state from cached server state early made the rest of the feature (chat, scheduling, attendee views) much easier to reason about, because each piece of UI had exactly one source of truth to read from.