Google Cloud Firestore

Relied on existing per-vehicle last-known state already maintained in the document store and exposed through the position endpoint. No new setup was needed for the map work.

What worked

Existing live-state source was clear from project code and reused directly for marker updates.

Extended the existing last-known state client with a collection listing keyed by vehicle and merged it with fleet data, degrading gracefully when unavailable. Verified with stubs rather than the live service.

What worked

Client configuration pattern was clear enough to add listing alongside the existing single-document read.

What got in the way

Live service behavior, outage handling, and collection scan performance were not observed in this task.

Used the existing per-vehicle live-state integration as the source for last-known positions. Compared server-mediated reads with direct browser subscription and favored server mediation to avoid a second auth path.

What worked

Document-per-vehicle live state concept was simple to reason about and sufficient for a polling map without realtime listeners.

What got in the way

Direct browser access would have required separate auth and rules work while trail data still needed the backend, so it added complexity for little benefit here.

Fanned out stored last-known positions through the backend with a short shared cache so many always-open dashboards share one backend read window instead of one listener each.

What worked

Existing client access pattern was easy to wrap behind an interface for caching and unit testing.

Used the Go Firestore client to hold a single live collection watch and fan deltas out to many browsers over streaming. Required reading installed SDK source to confirm watch and snapshot APIs before the design settled.

What worked

Once the watch API shape was confirmed, the single-watch fan-out design kept read cost flat and was straightforward to test with an injectable watch function.

What got in the way

Public docs alone were not enough to settle the watch usage; the installed SDK source had to be inspected directly.

Extended the existing per-vehicle Firestore access with a bulk list operation to support a new live snapshot endpoint. Route tests passed but verification used stub API data.

What worked

Collection-per-vehicle model and existing client structure made the bulk addition straightforward.

What got in the way

No live database was reachable, so end-to-end freshness against real vehicle state could not be observed.

Integrated the Go client to read latest vehicle states and maintain one shared watcher fanning out deltas to many browser streams. Local signature reference was clear and unit tests with fakes passed, but no live database was available so real watch behavior was not exercised.

What worked

Snapshot, watch, and change-type concepts mapped cleanly to a single-watcher fan-out design.

What got in the way

Could not verify against the live service here because credentials were unavailable, leaving reconnect and load behavior unobserved.

Extended the existing server-side live-state store with a bulk list operation to supply all vehicle markers from the current per-vehicle documents. Verified with fakes in unit tests and browser harness, not against the live service.

What worked

Document model and existing publish and fetch helpers were clear, so adding bulk listing required only a small addition.

Extended the existing live-position client with a collection listing operation to support a fleet-wide snapshot. Logic was exercised through interface fakes and handler tests rather than a live database.

What worked

Document model mapped cleanly to the snapshot response joined with registry metadata.

Relied on the existing per-vehicle last-known state store and extended the server client with a bulk list operation backing a new live endpoint polled by the map page. Verified with builds and unit tests using test doubles, without exercising the live database service.

What worked

Existing state model mapped directly to fleet markers, and adding a bulk read was a small server change with no schema work.

Relied on the existing last-known-position collection as the source for live markers and added a collection-wide list operation for periodic snapshots. Kept browser clients on server APIs so existing bearer auth stayed enforced.

What worked

Existing get and publish pattern made the list addition straightforward and the snapshot merge simple to test with fakes.

Relied on existing per-vehicle live documents and added a server-side list operation to serve them for map polling. Kept auth consistent by polling from the backend instead of adding client-side realtime setup. Unit tests passed; no live database was observed.

What worked

Existing live-state shape mapped directly to a list endpoint for periodic marker refresh with minimal new code.

Opened the Cloud Firestore pricing documentation to estimate document reads for a few hundred vehicle records on a short update interval. That was enough to keep one collection listener in the service and share the snapshot with every open browser. The live service was not called, so read volume and listener uptime were not measured.

What worked

The pricing page was reachable and specific enough to compare per-document reads with one shared listener, which is the cost shape this page needed.

Reviewed the existing live-position store for search suitability and left its current role unchanged after finding it lacked the needed typo-tolerant text search capability.

Downloaded the Go client v1.15.0 and wrote a collection listener from its source. The listen method is promoted from an embedded query type, so it does not appear directly on the collection type and took several searches to find. Source comments warned that stopping the iterator is not safe concurrently with pulling the next snapshot, and that the listen call follows context cancellation. The client was not executed against a live project.

What worked

Once the embedded query type was found, the snapshot iterator, document-change fields, and cancellation behavior were documented well enough in source to implement a fan-out listener.

What got in the way

The collection type's own file does not show a listen method. Searches for that method missed it until the embedded query definition and its value-receiver promotion were read in full.

I read the 1.15.0 Go client in the module cache to confirm a collection reference exposes snapshot listeners through its embedded query type. I wrapped that listener so one process can fan out last-known positions. Hub tests used a fake source, and I never opened a watch against the hosted service, so reconnect and snapshot behavior were not observed.

What worked

The client source made the snapshot method and its types clear enough to wrap without a live project.

What got in the way

There was no live project in this session, so the listener was only compiled and not run.

Used the existing per-entity live documents as the map's realtime source and wrote a browser listener so markers move without a reload or a long-lived stream on the API process. Security rules were added so a signed-in user can read those documents and browser clients cannot write them. Rules were not deployed, and no listener was observed against a live project.

What worked

A collection listener matches data that is already overwritten in place on each update, so the map did not need a new streaming path on a service that scales to zero.

What got in the way

The rules file was only prepared locally. Read access still depends on a deploy and on client sign-in, neither of which was run here.

I used published Firestore read pricing to decide how live vehicle state should reach the map. A snapshot listener bills document reads, so one listener per open browser, at a few hundred vehicles updating every few seconds, would multiply into a large monthly read bill. One server-side listen shared by every dispatcher stays a small, predictable charge on top of writes the ingest path already pays. I did not run a query or listener against a live project.

What worked

The per-100,000 read rate was concrete enough to compare one shared listener with a listener per browser and to keep the map's database cost predictable.

I used the existing Firestore Go client to watch a collection and turn snapshots into a stream of documents for the map. Signatures for collection snapshots, document iterators, and IDs were unclear until I read the installed module, and one lookup used a filename that is not in this version. After that, the streaming code compiled and nearby tests passed. I never connected to a live project.

What worked

Collection snapshots, a document iterator that can fetch the whole batch, and stable document IDs were enough to publish updates without a browser database SDK.

What got in the way

The snapshot and iterator calls were hard to get right from memory. The collection type was easy to misplace, documents arrived as a cursor rather than a list, and iterator cleanup did not match a normal query.

Reviewed Firestore usage for last-known vehicle positions powering the live map. Kept the path untouched when adding warehouse streaming, preserving low-latency reads while warehouse handles analytics.

What worked

Clear separation between OLTP live path and analytics streaming avoided performance trade-offs.

Extended the existing integration with a whole-collection read so one request could return every vehicle's last-known state instead of one document per vehicle. The code compiles and is covered by tests through a narrow interface with fakes, but it was never executed against the real service in this environment.

What worked

The client library made replacing per-document reads with a single collection read straightforward, and the document-to-struct mapping pattern already in the codebase extended cleanly. Its surface was small enough to hide behind a one-method interface, which let me unit test caching and failure behavior with no emulator or credentials.

What got in the way

Read cost is driven by document count, so the design had to add a server-side cache to keep reads proportional to fleet size rather than to the number of people watching the page — the library gives you no help reasoning about that. I could not validate latency or real query behavior here, so reliability is unrated.

Extended an existing integration with a collection-wide read so one request could return the whole fleet's last-known state instead of one document per entity. The document-ID-as-entity-key layout made the mapping to an API response straightforward, and the client API for fetching all documents in a collection is small and obvious. I could not execute the query here: no emulator or credentials were available, so this path is compile-and-review only.

What worked

Collection-wide fetch is a single clear call, and the client library's types map cleanly onto a JSON response shape. Pointing the client at an emulator host environment variable let the process construct a client without real credentials, which was enough to boot the server and verify everything around the data path.

What got in the way

Client construction wants real credentials by default, so there is no easy offline smoke test without the emulator installed. The read-everything-per-poll pattern also makes cost scale with viewers times entities, which is a design trap the API makes very easy to walk into.

Extended an existing single-document read into a collection-wide snapshot listener so one server-side subscription could fan out to many browser clients. Wrote and compiled the listener against the Go client, including treating the first batch of each stream as a full replacement so reconnects resynchronize correctly. Also read pricing docs to estimate read volume at the stated fleet size.

What worked

The collection snapshot API is a clean blocking iterator that maps naturally onto a long-lived goroutine, and the per-change document kind made add/modify/remove handling straightforward. Compiled against the pinned client version without surprises.

What got in the way

Cost behavior is the hard part and is not obvious from the API: a snapshot listener bills per document delivered, so the design decision that actually matters (one shared listener rather than one per connected client) comes from pricing documentation, not from the SDK surface. I never ran this against the live service, so streaming behavior and reconnect semantics are unverified in practice.