Odtnhj

For API work I tend to cache 3rd party API responses by wrapping the http request around Redis get / set functions e.g:

import http from 'request-promise-native';
import redis from 'redis';
import bluebird from 'bluebird';

bluebird.promisifyAll(redis.RedisClient.prototype);
bluebird.promisifyAll(redis.Multi.prototype);

const redisClient = redis.createClient();

const getData = async id => 
 const cacheKey = `some-key-$id`;
 const cached = await redisClient.getAsync(cacheKey);

 if (cached) 
 return JSON.parse(cached);
 

 const response = await http(
 method: 'GET',
 url: `https://example.com/$id`,
 json: true,
 );

 redisClient.set(cacheKey, JSON.stringify(response), 'EX', 3600);
 return response;

This works well for a few API calls, but when you have a complex API with tens or hundreds of calls this approach is harder to maintain and toggle.

It would be ideal if this could be plugged into the http request library (in this case request-promise-native).

Can you recommend a better solution?

The design pattern you mentioned is Decorator function and you can also achieve it with wrapping your api calls with a custom function which calles redis each time before reaching out to the API.

but it's defiantly should not be part of request-promise-native, it's too permissive and opinionated.

when building high-load/high-concurrency applications you should consider
not doing lot's of cpu consuming tasks / long-blocking tasks / allocations on hot path (creating lot's of new objects)

Redis performance is bounded to the cpu(1-code) & memory & network of your machine , and a simple vm (2 cores, 4gb, 1gbit network) can handle tens of K concurrently.

your nodejs app will blow the cpu/memory before something happens to redis .