Boost Browser Data Handling: RxJS-Wrapped Fetch API for Smart Caching & Updates

Issues with Fetch API

When a client needs a resource such as http://api/v1/foo/123, a simple fetch('http://api/v1/foo/123') returns a Promise. This works for simple news‑feed sites, but complex SaaS consoles often require caching and data‑update notifications.

URI‑Based Caching Mechanism

A common solution is to wrap Fetch so that each request can be cached based on its URI, parameters, and method. Although this appears simple, it makes client code tightly coupled to server endpoints and complicates cache invalidation, especially when a resource is reachable via multiple URIs.

For example, a resource foo(id=123) might exist at /foo (list) and /foo/123 (detail). Updating the resource then requires enumerating all related URIs for cache busting.

Wrapping Fetch API with RxJS

The following diagram shows an RxJS‑wrapped Fetch request.

Each distinct resource URI is managed by a singleton FetchDataStore that encapsulates the Fetch process.

Example implementation for resource foo(id=123):

Lazy‑loaded cache : The observable becomes hot only after the first subscription, providing on‑demand data.

Passive update handling : Observers can react to server‑push events such as WebSocket messages.

Composable data streams : RxJS operators enable further transformation of the data flow.

However, callers must invoke a refetch function at appropriate times to keep all observers synchronized.

Further Improvements

Advanced SDKs (e.g., Teambition’s RxJS data‑isomorphic SDK) introduce a model schema—often expressed with TypeScript—to give each resource a stable identifier across contexts, and expose a unified Model interface for all data interactions, reducing direct API calls and simplifying view logic.

Remember: the more complex a system becomes, the higher the risk of bugs; strive for simplicity and efficiency.