|
| 1 | +# @loopback/http-caching-proxy |
| 2 | + |
| 3 | +A caching HTTP proxy for integration tests. |
| 4 | + |
| 5 | +**NOT SUITABLE FOR PRODUCTION USE!** |
| 6 | + |
| 7 | +## Overview |
| 8 | + |
| 9 | +Testing applications connecting to backend REST/SOAP services can be difficult: |
| 10 | +The backend service may be slow, apply rate limiting, etc. Integration tests |
| 11 | +become too slow in such case, which makes test-first development impractical. |
| 12 | + |
| 13 | +This can be addressed by setting up a snapshot-based mock server or using |
| 14 | +a caching HTTP client, but both of these solutions come with severe |
| 15 | +disadvantages: |
| 16 | + |
| 17 | + - When using a snapshot-based mock server, we must ensure that snapshots |
| 18 | + are up-to-date with the actual backend implementation. |
| 19 | + |
| 20 | + - Caching at HTTP-client side requires non-trivial changes of the application |
| 21 | + code. |
| 22 | + |
| 23 | +A filesystem-backed caching HTTP proxy offers a neat solution that combines |
| 24 | +caching and snapshots: |
| 25 | + |
| 26 | + - The first request is forwarded to the actual backend and the response |
| 27 | + is stored as a snapshot. |
| 28 | + - Subsequent requests are served by the proxy using the cached snaphost. |
| 29 | + - Snapshot older than a configured time are discarded and the first next |
| 30 | + request will fetch the real response from the backend. |
| 31 | + |
| 32 | +## Installation |
| 33 | + |
| 34 | +```sh |
| 35 | +npm install --save-dev @loopback/http-caching-proxy |
| 36 | +``` |
| 37 | + |
| 38 | +## Basic use |
| 39 | + |
| 40 | +Import the module at the top of your test file. |
| 41 | + |
| 42 | +```ts |
| 43 | +import {HttpCachingProxy} from '@loopback/http-caching-proxy'; |
| 44 | +``` |
| 45 | + |
| 46 | +Create a proxy instance during test-suite setup |
| 47 | +(typically in Mocha's `before` hook): |
| 48 | + |
| 49 | +```ts |
| 50 | +const proxy = new HttpCachingProxy({ |
| 51 | + // directory where to store recorded snapshots - required |
| 52 | + cachePath: path.resolve(__dirname, '.proxy-cache'), |
| 53 | + // port where to listen - 0 by default |
| 54 | + port: 0, |
| 55 | + // how often to re-validate snapshots (in milliseconds) - one day by default |
| 56 | + ttl: 24*60*60*1000, |
| 57 | +}); |
| 58 | +await proxy.start(); |
| 59 | +``` |
| 60 | + |
| 61 | +In your tests, configure the client library to use the caching proxy. |
| 62 | +Below is an example configuration for |
| 63 | +[request](https://www.npmjs.com/package/request): |
| 64 | + |
| 65 | +```ts |
| 66 | +request = request.defaults({ |
| 67 | + proxy: proxy.url, |
| 68 | + // Disable tunneling of HTTPS requests - this is required for HTTPS! |
| 69 | + tunnel: false |
| 70 | +}); |
| 71 | +``` |
| 72 | + |
| 73 | +Finally, stop the proxy when the test suite is done |
| 74 | +(typically in Mocha's `after` hook): |
| 75 | + |
| 76 | +```ts |
| 77 | +await proxy.stop(); |
| 78 | +``` |
| 79 | + |
| 80 | +## API Documentation |
| 81 | + |
| 82 | +See the auto-generated documentation at |
| 83 | +[loopback.io](http://apidocs.loopback.io/@loopback%2fdocs/caching-proxy.html) |
| 84 | + |
| 85 | +## Contributions |
| 86 | + |
| 87 | +- [Guidelines](https://github.com/strongloop/loopback-next/blob/master/docs/CONTRIBUTING.md) |
| 88 | +- [Join the team](https://github.com/strongloop/loopback-next/issues/110) |
| 89 | + |
| 90 | +## Tests |
| 91 | + |
| 92 | +Run `npm test` from the root folder. |
| 93 | + |
| 94 | +## Contributors |
| 95 | + |
| 96 | +See |
| 97 | +[all contributors](https://github.com/strongloop/loopback-next/graphs/contributors). |
| 98 | + |
| 99 | +## License |
| 100 | + |
| 101 | +MIT |
0 commit comments