⚡️ a simple abstraction over fetch to enable easy management of request/response flows

This package provides EmberData's RequestManager, a framework agnostic library that can be integrated with any Javascript application to make fetch happen.

• Installation
• Basic Usage
• Architecture
• Usage
  • Making Requests
    • Using The Response
  • Request Handlers
    • Handling Errors
    • Handling Abort
    • Stream Currying
    • Automatic Currying
  • Using as a Service
    • Using with @ember-data/store
    • Using with ember-data

Installation

Install using your javascript package manager of choice. For instance with pnpm

1pnpm add @ember-data/request

Tagged Releases

• 
• 
• 
• 
• 

🚀 Basic Usage

A RequestManager provides a request/response flow in which configured handlers are successively given the opportunity to handle, modify, or pass-along a request.

The RequestManager on its own does not know how to fulfill requests. For this we must register at least one handler. A basic Fetch handler is provided that will take the request options provided and execute fetch.

1import RequestManager from '@ember-data/request';
2import Fetch from '@ember-data/request/fetch';
3import { apiUrl } from './config';
4
5// ... create manager and add our Fetch handler
6const manager = new RequestManager()
7  .use([Fetch]);
8
9// ... execute a request
10const response = await manager.request({
11  url: `${apiUrl}/users`
12});

🪜 Architecture

A RequestManager receives a request and manages fulfillment via configured handlers. It may be used standalone from the rest of EmberData and is not specific to any library or framework.

1flowchart LR
2    A[fa:fa-terminal App] <--> B{{fa:fa-sitemap RequestManager}}
3    B <--> C[(fa:fa-database Source)]

Each handler may choose to fulfill the request using some source of data or to pass the request along to other handlers.

1flowchart LR
2    A[fa:fa-terminal App] <--> B{{fa:fa-sitemap RequestManager}}
3    B <--> C(handler)
4    C <--> E(handler)
5    E <--> F(handler)
6    C <--> D[(fa:fa-database Source)]
7    E <--> G[(fa:fa-database Source)]
8    F <--> H[(fa:fa-database Source)]

The same or a separate instance of a RequestManager may also be used to fulfill requests issued by EmberData{Store}

1flowchart LR
2    A[fa:fa-terminal App] <--> D{fa:fa-code-fork Store}
3    B{{fa:fa-sitemap RequestManager}} <--> C[(fa:fa-database Source)]
4    D <--> E[(fa:fa-archive Cache)]
5    D <--> B
6    click D href "https://github.com/emberjs/data/tree/main/packages/store" "Go to @ember-data/store" _blank
7    click E href "https://github.com/emberjs/data/tree/main/packages/json-api" "Go to @ember-data/json-api" _blank
8    style D color:#58a6ff;
9    style E color:#58a6ff;

When the same instance is used by both this allows for simple coordination throughout the application. Requests issued by the Store will use the in-memory cache and return hydrated responses, requests issued directly to the RequestManager will skip the in-memory cache and return raw responses.

1flowchart LR
2    A[fa:fa-terminal App] <--> B{{fa:fa-sitemap RequestManager}}
3    B <--> C[(fa:fa-database Source)]
4    A <--> D{fa:fa-code-fork Store}
5    D <--> E[(fa:fa-archive Cache)]
6    D <--> B
7    click D href "https://github.com/emberjs/data/tree/main/packages/store" "Go to @ember-data/store" _blank
8    click E href "https://github.com/emberjs/data/tree/main/packages/json-api" "Go to @ember-data/json-api" _blank
9    style D color:#58a6ff;
10    style E color:#58a6ff;

---

Usage

1const userList = await manager.request({
2  url: `/api/v1/users.list`
3});
4
5const users = userList.content;

---

Making Requests

RequestManager has a single asyncronous method as it's API: request

1class RequestManager {
2  request<T>(req: RequestInfo): Future<T>;
3}

manager.request(<RequestInfo>) accepts an object containing the information necessary for the request to be handled successfully.

These options extend the options provided to fetch, and can accept a Request. All properties accepted by Request options and fetch options are valid.

1interface RequestInfo extends FetchOptions {
2  op?: string;
3  store?: Store;
4
5  url: string;
6  /**
7   * data that a handler should convert into 
8   * the query (GET) or body (POST)
9   */
10  data?: Record<string, unknown>;
11  /**
12   * options specifically intended for handlers
13   * to utilize to process the request
14   */
15  options?: Record<string, unknown>;
16}

note providing a signal is unnecessary as an AbortController is automatically provided if none is present.

---

Using the Response

manager.request returns a Future, which allows access to limited information about the request while it is still pending and fulfills with the final state when the request completes and the response has been read.

1const usersFuture = manager.request({
2  url: `/api/v1/users.list`
3});

A Future is cancellable via abort.

1usersFuture.abort();

Handlers may optionally expose a ReadableStream to the Future for streaming data; however, when doing so the handler should not resolve until it has fully read the response stream itself.

1interface Future<T> extends Promise<StructuredDocument<T>> {
2  abort(): void;
3
4  async getStream(): ReadableStream | null;
5}

A Future resolves or rejects with a StructuredDocument.

1interface StructuredDocument<T> {
2  request: RequestInfo;
3  response: ResponseInfo | null;
4  content?: T;
5  error?: Error;
6}

The RequestInfo specified by document.request is the same as originally provided to manager.request. If any handler fulfilled this request using different request info it is not represented here. This contract helps to ensure that retry and caching are possible since the original arguments are correctly preserved. This also allows handlers to "fork" the request or fulfill from multiple sources without the details of fulfillment muddying the original request.

The ResponseInfo is a serializable fulfilled subset of a Response if set via setResponse. If no response was ever set this will be null.

1/**
2 * All readonly properties available on a Response
3 * 
4 */
5interface ResponseInfo {
6  headers?: Record<string, string>;
7  ok?: boolean;
8  redirected?: boolean;
9  status?: HTTPStatusCode;
10  statusText?: string;
11  type?: 'basic' | 'cors';
12  url?: string;
13}

---

Request Handlers

Requests are fulfilled by handlers. A handler receives the request context as well as a next function with which to pass along a request to the next handler if it so chooses.

A handler may be any object with a request method. This allows both stateful and non-stateful handlers to be utilized.

If a handler calls next, it receives a Future which resolves to a StructuredDocument that it can then compose how it sees fit with its own response.

1
2type NextFn<P> = (req: RequestInfo) => Future<P>;
3
4interface Handler {
5  async request<T>(context: RequestContext, next: NextFn<P>): T;
6}

RequestContext contains a readonly version of the RequestInfo as well as a few methods for building up the StructuredDocument and Future that will be part of the response.

1interface RequestContext<T> {
2  readonly request: RequestInfo;
3
4  setStream(stream: ReadableStream | Promise<ReadableStream>): void;
5  setResponse(response: Response | ResponseInfo): void;
6}

A basic fetch handler with support for streaming content updates while the download is still underway might look like the following, where we use response.clone() to tee the ReadableStream into two streams.

A more efficient handler might read from the response stream, building up the response content before passing along the chunk downstream.

1const FetchHandler = {
2  async request(context) {
3    const response = await fetch(context.request);
4    context.setResponse(reponse);
5    context.setStream(response.clone().body);
6
7    return response.json();
8  }
9}

Request handlers are registered by configuring the manager via use

1manager.use([Handler1, Handler2])

Handlers will be invoked in the order they are registered ("fifo", first-in first-out), and may only be registered up until the first request is made. It is recommended but not required to register all handlers at one time in order to ensure explicitly visible handler ordering.

---

Handling Errors

Each handler in the chain can catch errors from upstream and choose to either handle the error, re-throw the error, or throw a new error.

1const MAX_RETRIES = 5;
2
3const Handler = {
4  async request(context, next) {
5    let attempts = 0;
6
7    while (attempts < MAX_RETRIES) {
8      attempts++;
9      try {
10        const response = await next(context.request);
11        return response;
12      } catch (e) {
13        if (isTimeoutError(e) && attempts < MAX_RETRIES) {
14          // retry request
15          continue;
16        }
17        // rethrow if it is not a timeout error
18        throw e;
19      }
20    }
21  }
22}

---

Handling Abort

Aborting a request will reject the current handler in the chain. However, every handler can potentially catch this error. If your handler needs to separate AbortError from other Error types, it is recommended to check context.request.signal.aborted (or if a custom controller was supplied controller.signal.aborted).

In this manner it is possible for a request to recover from an abort and still proceed; however, as a best practice this should be used for necessary cleanup only and the original AbortError rethrown if the abort signal comes from the root controller.

AbortControllers are Always Present and Always Entangled

If the initial request does not supply an AbortController, one will be generated.

The signal for this controller is automatically added to the request passed into the first handler.

Each handler has the option to supply a new controller to the request when calling next. If a new controller is provided it will be automatically entangled with the root controller. If the root controller aborts, so will any entangled controllers.

If an entangled controller aborts, the root controller will not abort. This allows for advanced request-flow scenarios to abort subsections of the request tree without aborting the entire request.

---

Stream Currying

RequestManager.request and next differ from fetch in one crucial detail in that the outer Promise resolves only once the response stream has been processed.

For context, it helps to understand a few of the use-cases that RequestManager is intended to allow.

• to manage and return streaming content (such as video files)
• to fulfill a request from multiple sources or by splitting one request into multiple requests
  • for instance one API call for a user and another for the user's friends
  • or e.g. fulfilling part of the request from one source (one API, in-memory, localStorage, IndexedDB etc.) and the rest from another source (a different API, a WebWorker, etc.)
• to coalesce multiple requests
• to decorate a request with additional info
  • e.g. an Auth handler that ensures the correct tokens or headers or cookies are attached.

await fetch(<req>) resolves at the moment headers are received. This allows for the body of the request to be processed as a stream by application code while chunks are still being received by the browser.

When an app chooses to await response.json() what occurs is the browser reads the stream to completion and then returns the result. Additionally, this stream may only be read once.

The RequestManager preserves this ability to subscribe to and utilize the stream by either the application or the handler – thereby delivering the full power and flexibility of native APIs – without restricting developers in ways that lead to complicated workarounds.

Each handler may call setStream only once, but may do so at any time until the promise that the handler returns has resolved. The associated promise returned by calling future.getStream will resolve with the stream set by setStream if that method is called, or null if that method has not been called by the time that the handler's request method has resolved.

Handlers that do not create a stream of their own, but which call next, should defensively pipe the stream forward. While this is not required (see automatic currying below) it is better to do so in most cases as otherwise the stream may not become available to downstream handlers or the application until the upstream handler has fully read it.

1context.setStream(future.getStream());

Handlers that either call next multiple times or otherwise have reason to create multiple fetch requests should either choose to return no stream, meaningfully combine the streams, or select a single prioritized stream.

Of course, any handler may choose to read and handle the stream, and return either no stream or a different stream in the process.

To conditionally stream, you can check if the user has requested the stream with context.hasRequestedStream.

---

Automatic Currying of Stream and Response

In order to simplify the common case for handlers which decorate a request, if next is called only a single time and setResponse was never called by the handler, the response set by the next handler in the chain will be applied to that handler's outcome. For instance, this makes the following pattern possible return (await next(<req>)).content;.

Similarly, if next is called only a single time and neither setStream nor getStream was called, we automatically curry the stream from the future returned by next onto the future returned by the handler.

Finally, if the return value of a handler is a Future, we curry content and errors as well, thus enabling the simplest form return next(<req>).

In the case of the Future being returned, Stream proxying is automatic and immediate and does not wait for the Future to resolve.

---

Using with @ember-data/store

To have a request service unique to a Store:

1import Store, { CacheHandler } from '@ember-data/store';
2import RequestManager from '@ember-data/request';
3import Fetch from '@ember-data/request/fetch';
4
5class extends Store {
6  requestManager = new RequestManager()
7    .use([Fetch])
8    .useCache(CacheHandler);
9}

---

Using as a Service

Some applications will desire to have direct service-level access to the RequestManager, which can be achieved using module-state patterns for singletons, or for Ember applications by exporting the manager as a service.

services/request.ts

1import { CacheHandler } from '@ember-data/store';
2import RequestManager from '@ember-data/request';
3import Fetch from '@ember-data/request/fetch';
4import Auth from 'app/services/ember-data-handler';
5
6export default {
7  create() {
8    return new RequestManager()
9      .use([Auth, Fetch]) 
10      .useCache(CacheHandler);
11  }
12}

---

Using with ember-data

If using the package ember-data, the following configuration will automatically be done in order to preserve the legacy Adapter and Serializer behavior. Additional handlers or a service injection like the above would need to be done by the consuming application in order to make broader use of RequestManager.

1import Store from 'ember-data/store';
2import { CacheHandler } from '@ember-data/store';
3import RequestManager from '@ember-data/request';
4import Fetch from '@ember-data/request/fetch';
5import { LegacyNetworkHandler } from '@ember-data/legacy-compat';
6
7export default class extends Store {
8  requestManager = new RequestManager()
9    .use([LegacyNetworkHandler, Fetch])
10    .useCache(CacheHandler);
11}

To provide a different configuration, import and extend ember-data/store. The default configuration will be ignored if the requestManager property is set, though the store will still register the CacheHandler.

For usage of the store's requestManager via store.request(<req>) see the Store documentation.