Шаблон проектирования: объединение http-запросов с подключаемым механизмом кэширования Redis.

Question

Для работы с API я склонен кешировать сторонние ответы API, заключая HTTP-запрос в функции Redis get / set, например:

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;
}

Это хорошо работает для нескольких вызовов API, но если у вас сложный API с десятками или сотнями вызовов, такой подход сложнее поддерживать и переключать.

Было бы идеально, если бы его можно было подключить к библиотеке http-запросов (в данном случае request-promise-native).

Можете ли вы порекомендовать лучшее решение?

Answer 1

Шаблон проектирования, который вы упомянули, является функцией Decorator, и вы также можете добиться этого, заключив в свои вызовы API пользовательскую функцию, которая каждый раз вызывает redis перед обращением к API.

, но это не должно бытьчасть запроса-обещания-родного, это слишком уместно и самоуверенно.

при создании приложений с высокой нагрузкой / высоким параллелизмом следует учитывать, что не нужно выполнять много задач, потребляющих ресурсы процессора / задач с длительной блокировкой / выделять ресурсы на горячем пути (создавая множество новых объектов)

Redisпроизводительность ограничена процессором (1 код), памятью и сетью вашего компьютера, а простой виртуальный компьютер (2 ядра, 4 ГБ, 1 Гбит) может одновременно обрабатывать десятки килограмм.

ваше приложение nodejs будет работатьпроцессор / память, прежде чем что-то случится с redis.