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.