Как сконфигурировать NextJS сервер с полной поддержкой кэширования в Redis

1. Next.js — JS фреймворк, созданный поверх React.js для создания веб-приложения с поддержкой функционала отрисовки приложения на стороне сервера 

2. Redis (Remote Dictionary Server)- это быстрое хранилище данных типа «ключ‑значение» в памяти, активно используемое в разработке с целью повышения производительности сервисов

3. Кэш Redis позволяет максимально эффективно применять горизонтальное масштабирование вашего приложения, поскольку заставляет все инстансы приложения смотреть в единый источник данных, вместо использования локального стейта

4. В рамках данного гайда мы соберем собственный вариант сервера для фреймворка NextJS, добавив кэширование сгенерированых страниц и json файлов, содержащих пропсы этих страниц ( для ускорения навигации за счет префетчей)

Шаг 1. Установка NextJS

yarn create next-app

Шаг 2. Установка пакетов:

yarn add express redis node-gzip

Шаг 3. Создаем в  корне проекта файл server.js

const express = require('express') const next = require('next') const { promisify } = require('util') const {gzip} = require('node-gzip');  const client = redis.createClient('redis://localhost:6379') client.get = promisify(client.get)  const app = next({ dev: false }) const handle = app.getRequestHandler()  app.prepare().then(() => {    const server = express()    server.get('*', (req, res) => handle(req, res))    server.listen(3000, (err) => {     if ( err ) throw err     console.log(`> Ready on http://localhost:3000`)   }) }) 

1. Подключаем express для создания сервера

2. Подключаем next для создания базового обработчика запросов NextJS 

3. Подключаем пакет для сжатия 

4. Устанавливаем соединение с redis, и используем promisify, чтобы работать с промисами вместо колбэков.

5. Запускаем сервер и устанавливаем базовый обработчик  для всех запросов ( * ) через handle

Шаг 4. Добавляем команду  запуска сервера в package.json

  "scripts": {    ...     "start": "node server.js",    ...   },

Шаг 5. Формирование ключей

Для того, чтобы в полной мере использовать мощь Redis в NextJS, нам необходимо кэшировать 2 вида файлов: 

1. HTML, который отдается в браузер при серверной генерации страницы

2. JSON-файл для каждой страницы, который генерирует NextJS для клиентской навигации ( когда мы переходим на страницу NextJS запрашивает этот JSON файл и  использует для передачи пропсов страницы

Шаг 6. Создаем ключ  для SSR

const getSsrKey = (req) => {   return req.url }

Для данной задачи самым простым решением для формирования ключа будет взять url страницы

Шаг 7. Создаем ключ для JSON

const getJsonKey = (req) =>   req.path     .match(/\/([^\/]+)+/g)     .slice(3)     .join('')

Путь к JSON файлам в рамках фреймворка NextJS имеет вид /_next/data/<BUILD_ID>/your-page-name.json

Поэтому самой полезной частью этого пути является то, что идет после идентификатора сборки — your-page-name.json, поэтому его мы и будем брать для формирования ключа

Шаг 8. Создаем кэш HTML

async function ssrCache(req, res) {    const key = getSsrKey(req)     const cache = await client.get(key)    if ( cache ) {     return res.send(cache)   }    const data = await app.renderToHTML(req, res, req.path, { ...req.query, ...req.params })    if ( res.statusCode === 200 && data ) client.set(key, data)    return res.send(data) }

Для рендеринга страниц nextJS предоставляет метод renderToHTML. Поэтому наша задача состоит в том, чтобы: 

1. Попытаться получить значение из кэша Redis по ключу. 

2. Если кэш существует, то мгновенно отдать в браузер

3. Если же кэша нет, то отрендерить страницу с помощью метода renderToHTML

4. Если страница была отрендерена успешно, закэшировать полученный HTML, после чего отдать в браузер

Шаг 9. Создаем кэш JSON

async function jsonCache(req, res) {    const key = getJsonKey(req)    const cache = await client.get(key)    if ( cache ) {      const headersToWrite = {       'content-type': 'application/json',       'content-encoding': 'gzip'     }      const buffer = JSON.parse(cache, (k, v) => {        if ( v !== null && typeof v === 'object' && 'type' in v &&        v.type === 'Buffer' &&  'data' in v && Array.isArray(v.data) ) {         return Buffer.from(v.data)       }        return v     })      Object.entries(headersToWrite).forEach(([ key, value ]) => res.setHeader(key, value))      return res.send(buffer)    }    const rawResEnd = res.end   const rawResWrite = res.write   const chunks = []    const proxyWrite = new Proxy(res.write, {      apply(target, thisArg, args) {       const chunk = Buffer.from(args[ 0 ])       chunks.push(chunk)     }    })    res.write = proxyWrite    const data = await new Promise(async (resolve) => {      res.end = async (res) => {       resolve(res || chunks)     }      await app.render(req, res, req.path, {       ...req.query,       ...req.params     })    })    res.write = rawResWrite   res.end = rawResEnd    const isChunked = Array.isArray(data)   const response = isChunked ?  Buffer.concat(data) : (Buffer.from(data))   const serializedResponse = isChunked ? JSON.stringify(response) : (JSON.stringify(await gzip(response)))    if ( res.statusCode === 200 && data ) client.set(key, serializedResponse)    return res.end(response) }

С JSON кэшем ситуация немного сложнее. Для рендера JSON мы можем воспользоваться методом  render. Проблема заключается в том, что этот метод не возвращает никакого значения, а сразу отдает его в браузер. Таким образом, для решения данной задачи нам необходимо подменить функциональность следующих методов, которые используются для выдачи в браузер:

1. res.write — вместо того, чтобы выводить данные мы сделаем так, чтобы эти данные попадали в массив chunks.

2. res.end — вместо того, чтобы завершать процесс ответа будет сигнализировать нам о том, что в chunks уже лежат все необходимые для вывода данные, и мы можем начать с ним работать

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

4. Если кэша нет, то запоминаем базовые функции res.write и res.end в переменную, чтобы потом иметь возможность их восстановить

5. Переопределяем write и end прокси функциями, которые обсудили в пунктах 1 и 2

6. Рендерим контент с помощью render, но благодаря нашим прокси функциям он не будет отдан браузер, а удобно окажется в специально созданной нами переменной 

7. Восстанавливаем базовые версии функций write и end

8. Далее может быть два варианта того, как мы можем собрать ответ — если контент не чанкался, то тогда на выходе мы получим строку(JSON) и создадим буфер из нее, в ином случае соединяем кусочки, которые собрали с помощью проксирования функции write в единый буфер. 

9. Если мы получили успешный ответ, то сериализуем буфер, сжимаем (в случае необходимости) и сохраняем в кэше редиса

10. Завершаем ответ методом end

Шаг 11. Собираем все вместе 

Для SSR страниц мы применяем ssrCache, для JSON файлов — jsonCache

server.get('/', (req, res) => {   return ssrCache(req, res) })  server.get('/_next/data/*', async (req, res) => {   return jsonCache(req, res) })  server.get('*', (req, res) => handle(req, res))

Ссылка на репозиторий: https://github.com/IAlexanderI1994/next-redis-article

Благодарю за прочтение. Буду рад вашим вопросам и комментариям.