Caching Proxy

A CLI tool that starts a proxy server. It forwards requests to a real origin server and caches the responses. If the same request comes in again, it's served straight from the cache instead of hitting the origin server.

No npm dependencies — uses only Node.js's built-in http/https modules, so node index.js ... works with nothing to install.

File structure

caching-proxy/
├── index.js                    entry point: parses args, picks a mode
└── src/
    ├── args.js                 CLI argument parsing + usage text
    ├── state.js                shared temp-file so --clear-cache can
    │                           find the running server's port
    ├── cache.js                the cache store itself (Map wrapper)
    ├── server.js               the proxy server: cache check, forward
    │                           to origin, cache the response
    └── clear-cache-client.js   sends the "clear cache" request to a
                                running server

Usage

Start the proxy:

node index.js --port 3000 --origin http://dummyjson.com

Now requests to your proxy are forwarded to the origin:

curl http://localhost:3000/products/1

• First request -> forwarded to http://dummyjson.com/products/1, response is cached. Response header: X-Cache: MISS
• Second request to the same path -> served from cache, origin is not hit. Response header: X-Cache: HIT

Clear the cache without restarting the server:

node index.js --clear-cache

How it works

1. Parse CLI args — --port, --origin, or --clear-cache.
2. Cache store — an in-memory Map keyed by "METHOD path+query" (e.g. GET /products/1), storing { status, headers, body }.
3. On each request:
   • If it's a GET and the key is in the cache -> write back the cached status/headers/body, add X-Cache: HIT.
   • Otherwise -> forward the request (method, headers, body) to the origin via http/https, buffer the response, store it in the cache if it was a GET, and return it with X-Cache: MISS.
4. --clear-cache — a separate CLI invocation. It reads the running server's port from a small state file in the OS temp dir, then POSTs to an internal /__internal_clear_cache__ route on that same server, which calls cache.clear(). This is what lets --clear-cache actually affect the live server's cache rather than just this process's own (empty) one.

Design notes / things worth knowing if you extend this

• Only GET requests are cached. Caching POST/PUT/DELETE responses is usually wrong since those requests aren't idempotent/safe.
• The cache key includes the query string, so /items?page=1 and /items?page=2 are cached separately.
• Content-Length from the origin is preserved as-is since we buffer the full body before responding, so it stays accurate.
• Transfer-Encoding is stripped from cached/forwarded headers since we're sending a fixed-length buffered body, not a stream.
• The cache is in-memory and per-process: restarting the proxy always starts with an empty cache.

Possible extensions

• Add a TTL (max-age) so cache entries expire automatically.
• Add --clear-cache for a specific path instead of the whole cache.
• Persist the cache to disk so it survives restarts.
• Respect the origin's own Cache-Control/ETag headers instead of caching everything unconditionally.