Project 02 / Team contribution
MapTrack.
Asset workflows that stay responsive while data syncs.
I migrated Next.js data fetching to reactive RxDB queries and integrated local-first mutations with the existing Supabase replication.
- Focus
- Offline-first asset management
- Built with
- Next.js / TypeScript / RxDB / Supabase
- Status
- Team contribution · Sep 2025–Feb 2026
Project in brief
- The problem
- Asset, audit and timeline views needed to stay usable while local data and server updates changed.
- My contribution
- I migrated frontend data fetching and connected list and detail pages to RxDB.
- Key decision
- Read reactively from local data and update RxDB first for selected mutations, using the existing replication mechanism.
- Result
- The UI followed local changes while replication synchronized with Supabase; no latency benchmark is claimed.
Product-level visual references; these images do not identify my delivered screens or demonstrate the RxDB integration. Source: MapTrack Open either image to inspect it at full size.
01
Overview
MapTrack is an asset-tracking application. My part-time software engineering role covered Next.js interfaces for assets, audits and timelines.
Remote fetching alone did not cover the offline-first workflow. List pages, paginated results and detail views needed to reflect locally available data as it changed.
02
My work
I implemented frontend hooks and page integrations, and integrated the existing RxDB–Supabase replication. I did not build a separate conflict-resolution engine.
- Built asset, audit and timeline interfaces in Next.js.
- Implemented custom useLiveQuery and useLiveInfiniteQuery hooks for reactive list and detail data, including pagination.
- Integrated selected mutations with local RxDB updates before server synchronization.
- Handled soft-deleted records and kept query results consistent with replicated local data.
03
Technical decisions
Next.js interfaces read from RxDB through custom useLiveQuery and useLiveInfiniteQuery hooks. Selected mutations update RxDB first. Existing RxDB–Supabase replication synchronizes those changes with the server; reactive queries update the interface as local data changes.
- Frontend integration · my workuseLiveQuery and useLiveInfiniteQuery connect list/detail views to local data; selected mutations write to RxDB first.
- RxDB local databaseReactive results update the interface as local and replicated records change, including soft-deleted records.
- Existing platform infrastructureRxDB–Supabase replication synchronizes data and supplies the system’s conflict behavior.
My contribution covers frontend integration, query and pagination behavior, and selected local-first mutation flows. The underlying replication and conflict-resolution mechanism already existed.
- Used reactive local queries so views followed database changes without depending on another remote fetch.
- Kept pagination within reusable query hooks for list and detail integrations.
- Used the existing replication behavior for synchronization and conflicts rather than introducing a separate conflict engine.
04
Scope & status
Testing and validation
This account is based on my implementation work and contribution details. No public employer source, automated-test report or performance benchmark is attached to this case study.
Migrated frontend data access to an offline-first approach across asset-management workflows, with reactive UI updates during synchronization.
- Local data can lag the server while disconnected; reactive queries reflect available local state rather than guarantee immediate global consistency.
- Soft deletion and replicated changes must be handled consistently by list and detail queries.
- Exact replication configuration and conflict policies are outside the scope described here.
What I learned
A responsive local update and a server-confirmed update are different states.
Reusable reactive hooks need to account for pagination and deleted records as well as normal results.