@edx/frontend-platform 4.6.2 → 4.6.3

package/docs/decisions/0003-consolidation-into-frontend-platform.rst

@@ -1,71 +0,0 @@
-Consolidation of libraries into frontend-platform
-=================================================
-
-Status
-------
-
-Accepted
-
-Context
--------
-
-The frontend-platform repository replaces five earlier repositories:
-
-- edx/frontend-analytics
-- edx/frontend-auth
-- edx/frontend-base
-- edx/frontend-i18n
-- edx/frontend-logging
-
-We found that development across these five libraries was growing very difficult in a number of ways.
-
-Dependency graph complexity
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The overhead involved in maintaining individual packages and semantic version numbers was very difficult to reason about and maintain.  Updates to low-level packages tended to cause cascading updates through the dependency tree.  If a breaking change or incompatibility present in the tree forces dependent packages to absorb unrelated work, it can be very difficult to realize it's happening,  decreasing developer velocity and destabilizing our applications.
-
-As a rough illustration of this complexity:
-
-- 12 Micro-frontends depend on 5 libraries. (60 edges max)
-- 12 Micro-frontends depend on 5 reusable organisms (headers, footers, Paragon) (60 edges max)
-- 5 Reusable organisms depend on the 5 libraries. (25 edges max)
-- The 5 libraries sometimes depend on each other. (8 edges total)
-
-This graph has 153 possible edges, each of which represents a version number with its own set of compatibilities.  By combining the libraries, we drop the number of edges to 77.  Further combining some of our reusable organisms could get this number as low as 51.
-
-For a single micro-frontend, these numbers go from 43 to 11, then 9.
-
-Difficult cross-cutting feature development
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Often we've found that features and bug fixes require us to work in several of the above repositories simultaneously.  Getting npm to link packages from peer directories is tedious and error prone, making this kind of work difficult to get right.
-
-Interdependent services
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Going along with the difficulty of cross-cutting concerns, we realized at some point that many of packages were simply rather inter-connected.  Meaningful features and behaviors span packages, especially with respect to frontend-base's usage of the other libraries.  This means that validating correct behavior requires a fully functioning system; developing the libraries in isolation prevented us from doing substantive integration testing.
-
-Decision
---------
-
-By collapsing these libraries into a single repository published together under a single version number, we drastically reduce the layers of complexity involved in publishing new library versions.
-Note that this is a tactical technology choice - architecturally and strategically, the libraries are still independent and contain strong boundaries isolating them from each other.
-
-Note that we've preserved the platform's ability to utilize different service implementations, meaning that using the platform does not preclude applications from providing customized/extended functionality.  This means that we haven't really lost much flexibility by the consolidation.
-
-Alternatives
-------------
-
-We strongly considered making a Lerna monorepo with each of the original five packages published with its own version number.  There were two problems with this approach - first, it wouldn't address the dependency graph complexity, which was one of the most difficult-to-reason aspects of the original repositories.  Secondary to that, our usage of babel and building to a dist directory erases some of the developer experience benefits of using Lerna.  One of Lerna's strengths is that it automatically rewires your package.json dependencies to point at other packages in the repository, rather than pulling them down from the package registry.  Since we have a build step, we'd have to manually build each package any time we wanted to use it, which isn't all that different from what we had to do with the five separate repos.  Lerna just didn't really seem worth it.
-
-Adoption
---------
-
-As of this writing, frontend-platform is in use in four of our existing micro-frontends.  It's our intention to help teams migrate the others (approximately 8) to use the platform as well, and to archive the five legacy implementations mentioned above.
-
-The platform's API surface is very similar to the original five libraries, simply with a different import package.  If necessary, we expect that consumers of the old libraries will be able to do gradual, partial upgrades by cutting over individual libraries until they reach full adoption.
-
-Consequences
-------------
-
-If we collapse these libraries into a single versioned platform, consumers of the platform (applications) may still have to absorb undesired breaking changes at times, but we've greatly reduced the complexity of doing so.  Updating an application or dependent library involves consulting a single changelog for breaking changes, rather than five and trying to reason which are compatible with each other.

package/docs/decisions/0004-axios-caching-implementation.rst

@@ -1,88 +0,0 @@
-Axios Caching Layer Implementation
-=================================================
-
-Status
-------
-
-Accepted
-
-Context
--------
-
-It was noticed that on a lot of pages the same API calls are repeatedly being made as the user navigates around the website. The data being returned from these requests doesn't change between page loads leading to the same endpoints reloading the same data repeatedly. We decided that we wanted to avoid repeatedly loading unchanged data and reuse the data that was in the response from the initial load.
-
-We think it's beneficial to cut as much overhead as possible so each page becomes interactive more quickly.
-
-We decided to add a frontend caching layer to the AxiosJwtAuthService by leveraging an already existing npm package: `axios-cache-adapter <https://www.npmjs.com/package/axios-cache-adapter>`_
-
-Having a frontend caching layer would also allow for a stale version of a page to be displayed for a short amount of time in the case of a backend outage.
-
-When Frontend Caching Should Be Used
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The frontend cache should be used to eliminate the reloading of unchanged data as a user navigates between different pages in the application. It shouldn't be used to reduce the number of times multiple components on the same page try to make the same network call. Reducing the number of times the same network call is made on a single page should be done by moving the call higher up in the hierarchy so the call only gets made once and all lower level components are able to access the response data from it.
-
-Requests that are good candidates to use frontend caching are ones that:
- * The data being returned changes very infrequently, and independently from the actions of the user on the page
-
-   - For example changes made by a background job or an admin
-
- * The data being returned isn't specific to the authenticated user
-
- * The data returned is specific to the authenticated user but front end does not make the request when there isn't an authenticated user
-
-It should not be used as the only caching strategy that gets used. It is preferable to use a serverside caching strategy in conjunction with frontend caching.
-
-How To Use Frontend Caching
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The frontend caching layer can be used by passing {useCache: true} into the function that gets the httpClient.
-
-e.g.
-    service.getAuthenticatedHttpClient({ useCache: true });
-
-By default the response for a GET request will be stored in IndexedDB for 5 minutes and that cached value will get invalidated on any POST, PUT, PATCH, or DELETE request made to the same url. The caching layer also works with the standard cache-control headers: max-age, no-cache, and no-store
-
-Each request can also override the default cache configurations. `The How To document about caching <https://github.com/openedx/frontend-platform/blob/master/docs/how_tos/caching.rst>`_ has more detailed examples about how this caching layer can be used.
-
-
-Implementation Details
-~~~~~~~~~~~~~~~~~~~~~~
-
-For both versions of the current AxiosJwtAuthService HTTP clients, the authenticated client and the base unauthenticated clients, there are now two additional versions that use the cache (i.e. CachedAuthenticated and CachedUnauthenticated). Bringing the total number of httpClient instances up to four.
-In order to keep the interface more simple the cached clients don’t have their own getter functions exposing this detail, in order to use the cached http client micro frontends pass in a param for using the cache with the current getter functions.
-
-In the case of the cached clients failing to get created the uncached clients will be returned and used instead.
-
-The async hydrateAuthenticatedUser function will continue only ever using the uncached authenticated HTTP client so there won't be any concerns about the cache changing expected behavior of authentication.
-
-Only the AxiosJwtAuthService currently has cached http clients.
-
-Decisions
----------
-
-By using the existing axios-cache-adapter we were able to avoid needing to implement our own caching strategy and forgo having micro frontends need to implement their own front end caching strategies.
-
-The default max-age for cached data was decided to be 5 minutes for now. 5 minutes was deemed to be a reasonable amount of time that was neither too long or too short. The assumption is made that users won’t be switching to different accounts on their browser frequently enough to have a wide impact on their experience.
-If they experience any impact at all then they will only see cached data for a maximum of 5 minutes. Micro frontends are also able to override the default cache time to suit their own needs.
-The default max-age can also be changed at a later time if the current default of 5 minutes is deemed to be inadequate.
-
-"Integration tests were added to ensure that the cache adapter does not break the current behavior of the existing interceptors. These tests make real HTTP requests to https://httpbin.org/ as suggested by the tests in the axios-cache-adapter source code."
-
-Alternatives
-------------
-
-We discussed the pros and cons of having a frontend-platform cache implementation for micro front ends to use versus micro front ends implementing their own front end caching strategies utilizing Local/Session storage, ETags, and endpoints utilizing Cache-Control headers.
-Having a frontend-platform caching solution be widely available to micro frontends was decided to be a good thing and micro frontends are still able to use other caching strategies in conjunction with the caching in frontend-platform.
-
-Adoption
---------
-
-As of this writing, only a few HTTP requests within `frontend-app-learner-portal-enterprise <http://github.com/openedx/frontend-app-learner-portal-enterprise>`_ have adopted using the cached clients. Usage of the cache clients is on an opt-in basis where micro frontends determine whether or not using the front end cache clients suits their needs.
-
-
-Consequences
-------------
-
-Axios is version locked to version 0.18.1 so per request overrides work until this issue gets resolved: https://github.com/RasCarlito/axios-cache-adapter/issues/99.
-At of this writing it seems that a fix for the issue might possibly be in version 0.20

package/docs/decisions/0005-token-null-after-successful-refresh.rst

@@ -1,69 +0,0 @@
-Access Token Null After Successful Refresh
-==========================================
-
-Status
-------
-
-Accepted
-
-Context
--------
-
-There are cases where our frontend authentication code requests an updated access token (JWT cookies), gets a successful response, but the cookies never appear. This results in the JavaScript error: "[frontend-auth] Access token is still null after successful refresh."
-
-Decision
---------
-
-Since we have been unable to determine root cause, the de facto decision is to allow this issue to continue to exist.
-
-This doc is less about capturing the decision, then to capture the background in-case anyone wishes to understand what has been attempted so far.
-
-Failed Hypotheses
------------------
-
-Several failed hypotheses have been tested to determine why this is happening:
-
-* Tested if caused by a race condition between getting the response and having the cookies set.
-
-  * See https://github.com/edx-unsupported/frontend-auth/pull/38/files
-
-* Tested if caused by cookies being disabled, by creating/reading a separate cookie.
-
-  * Failure noted in https://openedx.atlassian.net/browse/ARCH-948?focusedCommentId=401201
-
-* Tested if the cookies library has a bug by attempting vanilla javascript.
-
-  * Failure noted in https://openedx.atlassian.net/browse/ARCH-948?focusedCommentId=401201
-
-* Tested if caused by a difference between the browser time and server time, causing the cookie to expire on arrival.
-
-  * Only a small subset of the errors (~0.8%) had a time difference of >5 minutes.
-
-  * See https://github.com/openedx/frontend-platform/pull/207
-
-Additional Data
----------------
-
-Here is a query used in New Relic to find these errors in the Learning MFE::
-
-  SELECT count(*) From JavaScriptError
-  WHERE errorMessage = '[frontend-auth] Access token is still null after successful refresh.' AND
-    appName = 'prod-frontend-app-learning'
-  SINCE 4 days ago FACET userAgentName
-
-Almost all of these errors are seen in Safari (2.9 k), with the rest (166) found in Chrome and Microsoft Edge.
-
-Here is an adjusted query searching for errors with a difference of >5 minutes between the server and browser times::
-
-  SELECT count(*) From JavaScriptError
-  WHERE errorMessage = '[frontend-auth] Access token is still null after successful refresh.' AND
-    browserDriftSeconds > 60*5
-  SINCE 4 days ago FACET userAgentName
-
-There were only 24 of these found in Safari, or ~0.8% of all of these errors found in Safari.
-
-Lastly, at the time this data was captured (2021-08-17), this error type made up ~12% of all errors in Safari, and ~3.3% of all errors across all browsers in the Learning MFE.
-
-* It is unclear if these errors can be duplicated with special privacy settings in Safari (or other browsers).
-
-* We have not learned about this issue from Customer Support, but only from monitoring errors. Since we are not receiving the JWT cookies, we do not know the affected users.

package/docs/decisions/0006-middleware-support-for-http-clients.rst

@@ -1,44 +0,0 @@
-Middleware Support for HTTP clients
-===================================
-
-Status
-------
-
-Accepted
-
-Context
--------
-
-We currently expose HTTP clients(axios instances) via ``getAuthenticatedHttpClient`` and ``getHttpClient`` used to make API requests
-in our MFEs. There are instances where it would be helpful if consumers could apply middleware to these clients.
-For example the `axios-case-converter <https://www.npmjs.com/package/axios-case-converter>`_ package provides
-a middleware that handles snake-cased <-> camelCase conversions via axios interceptors. This middleware would allow our MFEs to
-avoid having to do this conversion manually.
-
-Decision
---------
-
-The ``initialize`` function provided in the initialize module initializes the ``AxiosJwtAuthService`` provided by ``@edx/frontend-platform``.
-We will add an optional param ``authMiddleware``, an array of middleware functions that will be applied to all http clients in
-the ``AxiosJwtAuthService``.
-
-Consumers will install the middleware they want to use and provide it to ``initialize``::
-
-    initialize({
-        messages: [appMessages],
-        requireAuthenticatedUser: true,
-        hydrateAuthenticatedUser: true,
-        authMiddleware: [axiosCaseConverter, (client) => axiosRetry(client, { retries: 3 })],
-    });
-
-If a consumer chooses not to use ``initialize`` and instead the ``configure`` function, the middleware can be passed in the options param::
-
-   configure({
-       loggingService: getLoggingService(),
-       config: getConfig(),
-       options: {
-            middleware: [axiosCaseConverter, (client) => axiosRetry(client, { retries: 3 })]
-       }
-    });
-
-We decided to let consumers install their own middleware packages, removing the need to install the dependency as part of ``@edx/frontend-platform``.

package/docs/decisions/0007-javascript-file-configuration.rst

@@ -1,143 +0,0 @@
-Promote JavaScript file configuration and deprecate environment variable configuration
-======================================================================================
-
-Status
-------
-
-Accepted
-
-Context
--------
-
-Our webpack build process allows us to set environment variables on the command
-line or via .env files.  These environment variables are available in the
-application via ``process.env``.
-
-The implementation of this uses templatization and string interpolation to
-replace any instance of ``process.env.XXXX`` with the value of the environment
-variable named ``XXXX``.  As an example, in our source code we may write::
-
-    const LMS_BASE_URL = process.env.LMS_BASE_URL;
-
-After the build process runs, the compiled source code will instead read::
-
-    const LMS_BASE_URL = 'http://localhost:18000';
-
-Put another way, `process.env` is not actually an object available at runtime,
-it's a templatization token that helps the build replace it with a string
-literal.
-
-This approach has several important limitations:
-
-- There's no way to add variables without hard-coding process.env.XXXX
-  somewhere in the file, complicating our ability to add additional
-  application-specific configuration without explicitly merging it into the
-  configuration document after it's been created in frontend-platform.
-- The method can *only* handle strings.
-
-  Other data types are converted to strings::
-
-    # Build command:
-    BOOLEAN_VAR=false NULL_VAR=null NUMBER_VAR=123 npm run build
-
-    ...
-
-    // Source code:
-    const BOOLEAN_VAR = process.env.BOOLEAN_VAR;
-    const NULL_VAR = process.env.NULL_VAR;
-    const NUMBER_VAR = process.env.NUMBER_VAR;
-
-    ...
-
-    // Compiled source after the build runs:
-    const BOOLEAN_VAR = "false";
-    const NULL_VAR = "null";
-    const NUMBER_VAR = "123";
-
-  This is not good!
-
-- It makes it very difficult to supply array and object configuration
-  variables, and unreasonable to supply class or function config since we'd
-  have to ``eval()`` them.
-
-Related to all this, frontend-platform has long had the ability to replace the
-implementations of its analytics, auth, and logging services, but no way to
-actually *configure* the app with a new implementation.  Because of the above
-limitations, there's no reasonable way to configure a JavaScript class via
-environment variables.
-
-Decision
---------
-
-For the above reasons, we will deprecate environment variable configuration in
-favor of JavaScript file configuration.
-
-This method makes use of an ``env.config.js`` file to supply configuration
-variables to an application::
-
-    const config = {
-      LMS_BASE_URL: 'http://localhost:18000',
-      BOOLEAN_VAR: false,
-      NULL_VAR: null,
-      NUMBER_VAR: 123
-    };
-
-    export default config;
-
-This file is imported by the frontend-build webpack build process if it exists,
-and expected by frontend-platform as part of its initialization process. If the
-file doesn't exist, frontend-build falls back to importing an empty object for
-backwards compatibility.  This functionality already exists today in
-frontend-build in preparation for using it here in frontend-platform.
-
-This interdependency creates a peerDependency for frontend-platform on `frontend-build v8.1.0 <frontend_build_810_>`_ or
-later.
-
-Using a JavaScript file for configuration is standard practice in the
-JavaScript/node community.  Babel, webpack, eslint, Jest, etc., all accept
-configuration via JavaScript files (which we take advantage of in
-frontend-build), so there is ample precedent for using a .js file for
-configuration.
-
-In order to achieve deprecation of environment variable configuration, we will
-follow the deprecation process described in
-`OEP-21: Deprecation and Removal <oep21_>`_. In addition, we will add
-build-time warnings to frontend-build indicating the deprecation of environment
-variable configuration.  Practically speaking, this will mean adjusting build
-processes throughout the community and in common tools like Tutor.
-
-Relationship to runtime configuration
-*************************************
-
-JavaScript file configuration is compatible with runtime MFE configuration.
-frontend-platform loads configuration in a predictable order:
-
-- environment variable config
-- optional handlers (commonly used to merge MFE-specific config in via additional
-  process.env variables)
-- JS file config
-- runtime config
-
-In the end, runtime config wins. That said, JS file config solves some use
-cases that runtime config can't solve around extensibility and customization.
-
-In the future if we deprecate environment variable config, it's likely that
-we keep both JS file config and runtime configuration around.  JS file config
-primarily to handle extensibility, and runtime config for everything else.
-
-Rejected Alternatives
----------------------
-
-Another option was to use JSON files for this purpose.  This solves some of our
-issues (limited use of non-string primitive data types) but is otherwise not
-nearly as expressive or flexible as using a JavaScript file directly.
-Anecdotally, in the past frontend-build used JSON versions of many of
-its configuration files (Babel, eslint, jest) but over time they were all
-converted to JavaScript files so we could express more complicated
-configuration needs.  Since one of the primary use cases and reasons we need a
-new configuration method is to allow developers to supply alternate
-implementations of frontend-platform's core services (analytics, logging), JSON
-was effectively a non-starter.
-
-.. _oep21: https://docs.openedx.org/projects/openedx-proposals/en/latest/processes/oep-0021-proc-deprecation.html
-.. _frontend_build_810: https://github.com/openedx/frontend-build/releases/tag/v8.1.0

package/docs/how_tos/automatic-case-conversion.rst

@@ -1,58 +0,0 @@
-#####################################################################
-How to: Convert SnakeCase to CamelCase automatically for API Requests
-#####################################################################
-
-Introduction
-************
-
-When using the HTTP client from ``@edx/frontend-platform``, you are making an API request to an
-Open edX service which requires you to handle snake-cased <-> camelCase conversions manually. The manual conversion quickly gets
-tedious, and is error prone if you forget to do it.
-
-Here is how you can configure the HTTP client to automatically convert snake_case <-> camelCase for you.
-
-How do I use configure automatic case conversion?
-*************************************************
-
-You want to install `axios-case-converter <https://www.npmjs.com/package/axios-case-converter>`_, and add it
-as a middleware when calling ``initialize`` in the consumer::
-
-    import axiosCaseConverter from 'axios-case-converter';
-
-    initialize({
-        messages: [],
-        requireAuthenticatedUser: true,
-        hydrateAuthenticatedUser: true,
-        authMiddleware: [axiosCaseConverter],
-    });
-
-Or, if you choose to use ``configure`` instead::
-
-    import axiosCaseConverter from 'axios-case-converter';
-
-    configure({
-        loggingService: getLoggingService(),
-        config: getConfig(),
-        options: {
-                middleware: [axiosCaseConverter, (client) => axiosRetry(client, { retries: 3 })]
-        }
-    });
-
-By default the middleware will convert camelCase -> snake_case for payloads, and snake_case -> camelCase for responses.
-If you want to customize middleware behavior, i.e. only have responses transformed, you can configure it like this::
-    initialize({
-        messages: [],
-        requireAuthenticatedUser: true,
-        hydrateAuthenticatedUser: true,
-        authMiddleware: [(client) => axiosCaseConverter(client, {
-            // options for the middleware
-            ignoreHeaders: true, // don't convert headers
-            caseMiddleware: {
-                requestInterceptor: (config) => {
-                    return config;
-                }
-            }
-        })],
-    });
-
-See `axios-case-converter <https://github.com/mpyw/axios-case-converter>`_ for more details on configurations supported by the package.

package/docs/how_tos/caching.rst

@@ -1,93 +0,0 @@
-############################
-How to: Caching API Requests
-############################
-
-.. contents:: Table of Contents
-
-Introduction
-************
-
-Often, a web application needs to make the same repeated API calls, where the data returned is mostly static (i.e., does not change often). In such situations, caching is a viable solution to prevent unnecessary and potentially expensive operations, resulting in increased performance and a better user experience.
-
-When considering caching options, there's a few approaches to consider:
-
-Server caching
-==============
-
-Server caching helps to limit the cost of an API request on the server and its dependent systems. When a client makes a request to the API, the server will check for a local copy of the requested resource. If the local resource exists, the server will respond with it; otherwise, the request is processed normally (e.g., performing database lookups). With this approach, the cost savings to the server may be significant, utilizing less resources.
-
-Client caching
-==============
-
-Client caching helps to limit the cost of an API request incurred by the user. Rather than relying on a API implementing server caching, commonly referenced data may be cached locally within the client (i.e., browser). Similar to server caching, on the first request of an API, the request will occur as usual but the response data will be stored in the client.
-
-However, on subsequent requests (within a given timeframe), the client will check if a copy of the requested resource exists. If it does, it will read from the client cache rather than making a network request to the API. This has the benefit of freeing up resources on the server as it no longer needs to handle repeat queries within a given timeframe.
-
-Typically, client caching stores data for a given time (e.g., 5 minutes) since it was last requested. This allows the client cache to be dynamic in the sense that data will be eventually consistent and unneeded local data can be cleared once it is no longer relevant.
-
-Hybrid caching
-==============
-
-Both server and client caching can be combined to provide best of both worlds. Regardless of how an API request is made, utilizing a hybrid approach will ensure data is read from a local cache first, whether that be on the server or the client.
-
-How do I use client caching with ``@edx/frontend-platform?``
-************************************************************
-
-The ``@edx/frontend-platform`` package supports an Axios HTTP client that uses client caching under the hood through the use of `axios-cache-interceptor <https://www.npmjs.com/package/axios-cache-interceptor>`_.
-
-Currently, `localForage <https://www.npmjs.com/package/localforage>`_ is configured to be the underlying storage; ``localForage`` is a package that provides a similar API to browser's localStorage, except is asynchronous (non-blocking). ``localForage`` is configured to prefer using IndexedDB, falling back to localStorage if browser support for IndexedDB is lacking. If all else fails, an in-memory store is used instead. IndexedDB is more performant and may contain a broader range (and volume) of data in comparison to localStorage (see `browser support <https://caniuse.com/indexeddb>`_ for IndexedDB).
-
-When importing an HTTP client from ``@edx/frontend-platform``, you may specify options for how you wish to configure the HTTP client::
-
-  import { getAuthenticatedHttpClient } from '@edx/frontend-platform';
-
-  // ``cachedHttpClient`` is configured to use client caching under the hood.
-  const cachedHttpClient = getAuthenticatedHttpClient({ useCache: true });
-
-The examples below demonstrate how to configure commonly used caching behavior on a per-request basis. For more use-cases, you may refer to the `axios-cache-interceptor documentation <https://axios-cache-interceptor.js.org/#/pages/per-request-configuration>`_.
-
-Overriding the request id
-=========================
-
-Every request passed through the axios-cache-interceptor interceptor has an id. Each request id is responsible for binding a request to its cache
-for referencing (or invalidating) it later.
-
-  const { id: requestId} = cachedHttpClient.get('/courses/', {
-    id: 'custom-id'
-  });
-
-Modify expiry behavior for a single request
-===========================================
-
-By default, API requests using the cached HTTP client will be cached for 5 minutes. However, cache options may be configured on a per-request basis::
-
-  cachedHttpClient.get('/courses/', {
-    cache: {
-      ttl: 15 * 60 * 1000, // 15 minutes instead of the default 5.
-    },
-  });
-
-Invalidate cache for a single request
-=====================================
-
-In certain situations, it may be necessary to invalidate cached data to force a true network request to the server::
-
-  cachedHttpClient.get('/courses/', {
-    cache: {
-      override: true, // This will replace the cache when the response arrives.
-    },
-  });
-
-To remove the cache of a request::
-
-    await axios.storage.remove('list-posts');
-
-
-Check if response is served from network or from cache
-======================================================
-
-If there is a need to know whether a response was served from the network (i.e., server) or from the local client cache, you may refer to the ``response.request`` object::
-
-  cachedHttpClient.get('/courses/').then((response) => {
-    console.log(response.cached); // will be true if served from the client cache, false otherwise
-  });