@appzmonster/fetch-interceptor - npm Package Compare versions

Comparing version 1.0.2 to 1.0.3

CHANGELOG.md

		# Change Log - @appzmonster/fetch-interceptor

		### 1.0.3 (Wednesday, 30 June 2021 10:10:00 GMT)

		- Modified some context in README.md.

		### 1.0.2 (Wednesday, 30 June 2021 09:41:00 GMT)
		@@ -4,0 +8,0 @@

package.json

		{
		"name": "@appzmonster/fetch-interceptor",
		"version": "1.0.2",
		"version": "1.0.3",
		"description": "Fetch-interceptor is a JavaScript library to enable request interceptor feature on Fetch API. The library extends Fetch API and uses fluent API design to allow chaining of one or multiple request interceptors to a Fetch API request.",
		@@ -5,0 +5,0 @@ "main": "./index.js",

README.md

		@@ -65,5 +65,5 @@ # Fetch-interceptor

		> *When a request is outgoing, the first added request interceptor gets to execute first follows by the second added interceptor so on so forth until the last added interceptor. Every request interceptor is passed both the `resource` and `init` arguments of the [Fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch) request. The request interceptor can manipulate these arguments and continue passing the arguments to the next request interceptor until the last interceptor. Finally, the request sends out using the manipulated arguments to the designated service API (`resource`). For example, if you chained 2 request interceptors A* and B with A interceptor adds a "`X-DataExpiry`" header to the request, when B interceptor is invoked, it has the "`X-DataExpiry`" header from A interceptor. B interceptor can modify the header and do any other processing to the request arguments.
		> *When a request is outgoing, the first added request interceptor executes first and the last added interceptor executes last. The [Fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch) arguments, `resource` and `init` is passed to the first added request interceptor for processing or modification. The first request interceptor can modify these arguments, do some additional actions and continue passing these arguments to the next request interceptor. This process continues until there is no more request interceptor down the line. After all request interceptors have executed their work, the request is sent out to the `resource` (usually a service API uri) using the arguments provided by the last request interceptor. For example, if you add 2 request interceptors A* and B, assuming A interceptor adds a "`X-DataExpiry`" header to the request, when the second B interceptor is invoked, it inherits the "`X-DataExpiry`" header added by previous A interceptor. B interceptor can overwrite the "`X-DataExpiry`"header from A if it needs to and do any other processing.

		> *When a request returns, the request interceptors are invoked in the reverse order* of how they are added. Using the same example above (A and B), B interceptor gets invoked first follows by A interceptor. In this case, if B interceptor modifies the response, when A interceptor is invoked, it receives the modified response from B instead of the original response from the service API.
		> *When a request returns, the request interceptors are invoked in the reverse order. Using the same example above (A* and B), the second B interceptor gets invoked first follows by A interceptor. In this case, if B interceptor modifies the response, A interceptor will receive B response when it is invoked and return this modified response to the caller.

		@@ -70,0 +70,0 @@ Chaining multiple request interceptors creates a very powerful fetch request. For example, in a typical [OAuth 2.0](https://oauth.net/2/pkce/) and [Microservice](https://microservices.io/) use case, very often you need to send a request with a bearer token which you exchange with an authorization server right before you initiate the request. With a microservice architecture, you also need to track or correlate all activities across multiple services from frontend to backend. Such use case is a good fit to use or chain multiple request interceptors - add 2 request interceptors, one to handle bearer token exchange plus header injection and another interceptor to create a correlation context that gets sent from frontend to all backend microservices.

		@@ -65,5 +65,5 @@ # Fetch-interceptor

		> *When a request is outgoing, the first added request interceptor gets to execute first follows by the second added interceptor so on so forth until the last added interceptor. Every request interceptor is passed both the `resource` and `init` arguments of the [Fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch) request. The request interceptor can manipulate these arguments and continue passing the arguments to the next request interceptor until the last interceptor. Finally, the request sends out using the manipulated arguments to the designated service API (`resource`). For example, if you chained 2 request interceptors A* and B with A interceptor adds a "`X-DataExpiry`" header to the request, when B interceptor is invoked, it has the "`X-DataExpiry`" header from A interceptor. B interceptor can modify the header and do any other processing to the request arguments.
		> *When a request is outgoing, the first added request interceptor executes first and the last added interceptor executes last. The [Fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch) arguments, `resource` and `init` is passed to the first added request interceptor for processing or modification. The first request interceptor can modify these arguments, do some additional actions and continue passing these arguments to the next request interceptor. This process continues until there is no more request interceptor down the line. After all request interceptors have executed their work, the request is sent out to the `resource` (usually a service API uri) using the arguments provided by the last request interceptor. For example, if you add 2 request interceptors A* and B, assuming A interceptor adds a "`X-DataExpiry`" header to the request, when the second B interceptor is invoked, it inherits the "`X-DataExpiry`" header added by previous A interceptor. B interceptor can overwrite the "`X-DataExpiry`"header from A if it needs to and do any other processing.

		> *When a request returns, the request interceptors are invoked in the reverse order* of how they are added. Using the same example above (A and B), B interceptor gets invoked first follows by A interceptor. In this case, if B interceptor modifies the response, when A interceptor is invoked, it receives the modified response from B instead of the original response from the service API.
		> *When a request returns, the request interceptors are invoked in the reverse order. Using the same example above (A* and B), the second B interceptor gets invoked first follows by A interceptor. In this case, if B interceptor modifies the response, A interceptor will receive B response when it is invoked and return this modified response to the caller.

		@@ -70,0 +70,0 @@ Chaining multiple request interceptors creates a very powerful fetch request. For example, in a typical [OAuth 2.0](https://oauth.net/2/pkce/) and [Microservice](https://microservices.io/) use case, very often you need to send a request with a bearer token which you exchange with an authorization server right before you initiate the request. With a microservice architecture, you also need to track or correlate all activities across multiple services from frontend to backend. Such use case is a good fit to use or chain multiple request interceptors - add 2 request interceptors, one to handle bearer token exchange plus header injection and another interceptor to create a correlation context that gets sent from frontend to all backend microservices.

@appzmonster/fetch-interceptor - npm Package Compare versions

New alerts

Fixed alerts

Improved metrics