Add redis and in-memory cache

[anxolin]

This PR adds our own caching logics

Caching

First of all, it adds a Fastify pluging caching to allow to easily define the cache-control headers.
It also adds in the fastify instance a cache object which allow to get/save objects from/to an abstract cache.

This allows us to not depend on any particular cache implementantion for the main caching logic.

Redis vs In-memory

The environment var allows now to specify:
REDIS_ENABLED=true (false by default)

EDIT: Now its enabled if you specify REDIS_HOST environment variable.

When Redis is enabled, the caching will happen in Redis. Otherwise, it will use an in-memory cache (not suitable for large applications in production)

Redis integration

Additionally, I added the redis plugin, which allows us to access the redis logic through the convenient fastify.redis object.

This would allow us to be able to access to more advance uses of redis to implement any of the services.

TODO: Pending to not load it if REDIS_ENABLED=false

Bff cache

Additionally, I've done a plugin so we can have our own logic to automatically cache things based on the cache-control directive.

It should be very easy to use now. Each endpoint will define its own caching policy using the cache-control directive

Let's see it with these 2 endpoints:

fastify.get('/hello', async function (request, reply) {
    await sleep(2000)
    reply.send({ hello: 'world' })
  });

  fastify.get('/hello-cached', async function (request, reply) {
    await sleep(2000)
    console.log('Setting cache header')
    reply.header(CACHE_CONTROL_HEADER, getCacheControlHeaderValue(10))
    reply.send({ hello: 'world' })
  });

Both endpoints return the same data after 2 seconds. The difference is /hello-cached returns a cache-control header. This header is observed by bffCache plugin and will cache its content for the instructed time.

Additionally, future requests it will return the cached content and will keep track of the TTL at the time of the request so it can inform the clients about it.

Test

Test hello endpoint

Execute several times:
curl -i http://localhost:3010/examples/hello

You should notice a 2seconds delay in the response every single time.

Also, there's no headers for cache-control or x-bff-cache

Test hello-cached endpoint

Execute this command:
curl -i http://localhost:3010/examples/hello-cached

Observe how after the first request, next requests are cached for 10 seconds. After that, you should experience the delay again. Additionally, the cache-control header should inform about the TTL so clients know when the resource is not consider fresh anymore.

Credentials

Added some envs to control the redis connection

REDIS_HOST=true
REDIS_PORT=6379
REDIS_USER=redis_user
REDIS_PASSWORD=redis_user

Follow ups

After this PR we still have some works to do:

• Persistance
• Schedule backup/dump of Redis
• Infrastructure setups

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Updated (UTC)
bff_legacy	⬜️ Ignored (Inspect)	Visit Preview	Jun 19, 2024 6:42am

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/@fastify/caching@8.3.0	None	+7	133 kB	matteo.collina
npm/@fastify/redis@6.2.0	Transitive: network	+8	886 kB	matteo.collina
npm/abstract-cache-redis@2.0.0	Transitive: network	+10	478 kB	jsumners
npm/fastify-caching@6.3.0	None	+10	146 kB	jsumners
npm/redis-errors@1.2.0	None	0	8.85 kB	bridgear

🚮 Removed packages: npm/ieee754@1.2.1, npm/is-core-module@2.12.1, npm/path-parse@1.0.7

View full report↗︎

[alfetopito]

A question about caching failed GET requests.

Also, what about adding the a Redis instance to the docker compose for local development?