LatamQChallenge: Análisis de Most Viewed Clips Retriever

Realizo un pequeño análisis de como hacerle frente al estrés de servidor al diseñar un endpoint.

hace un año   •   2 min de lectura

Por Andrés Tuñón
bueno esta vez no se me ocurrio un buen meme la verdad xD

Bueno esta vez estamos nocturnos, la última vez definí que Clips debe trabajar con un App Access Token y esta vez analizaré como implementar la solución.

Para obtener un App Access Token necesito utilizar el Flujo de Autorización de Client Credentials, un simple POST sin refresh token. Tengo 2 opciones:

Opción 1: Consultar reactívamente

El usuario entra a la pantalla consultando los clips; para lograr este flujo necesito hacer una consulta previa el endpoint de token.

Flujo de consulta
Flujo de consulta

Cada que el usuario pagina o busca los clips de algun streamer realiza el mismo flujo,  pero la idea tampoco es abusar del endpoint de token, se supone que los tokens se guardan.

Por esta razón, debo hacer una especie de caché para que reactivamente utilice el token si aún no ha vencido y en caso contrario pedir un nuevo token:

Investigué un poco y me encontré con un interesante memory-cache, se añade a la caja de herramientas para solucionar persistencia temporal en NextJS:

  • cookies
  • redis
  • memory cache
memory-cache
A simple in-memory cache. put(), get() and del(). Latest version: 0.2.0, last published: 5 years ago. Start using memory-cache in your project by running `npm i memory-cache`. There are 618 other projects in the npm registry using memory-cache.

Problemas

Si el usuario empieza a realizar múltiples llamadas o incluso varios clientes consultan al mismo tiempo, disparará el Rate Limit

Esto podría solventarlo utilizando un queue o un caché en el cliente para reducir la cantidad de llamadas posibles al mismo tiempo; pero es demasiada complejidad y opté por otra opción desacoplada:

Opción 2: Delegando el estrés del servidor

El endpoint de token al permitirme realizar consultas cuando quiera, me permite hacer todo en el servidor.

Por lo tanto se me ocurrió un scheduled job que cada cierto tiempo vaya recorriendo la tabla de streamers para traer sus clips y guardarlos en una tabla. De ese modo, el usuario consultará la tabla y no los endpoints.

El problema de Rate Limit se solventa gracias a colocar un intervalo considerable entre cada ejecución del job, pero falta algo.. manejar el cursor.

Se me ocurre guardar un campo llamado updatedAt para saber la ultima vez que se actualizaron los clips, de ese modo ordeno las filas y sabré cual fue el más viejo.

No olvidemos que debe haber una primera vez donde no hay ningún clip, por lo tanto debe haber una lógica que inicialice

Esto seria todo por hoy, se aproximan sorpresas interesantes ...

Corre la voz

Sigue leyendo