En este post iré un poco al grano y utilizaré muchos términos extraños y en inglés, hay mucha información condensada, disculpen.
Esta es una continuación del post anterior:
Un resumen de todos los cambios en esta especie de diagrama:
Han habido muchos cambios desde la idea inicial, por temas de rendimiento, alcance y otros puntos que iré desglosando a continuación:
Corrección de Relaciones
Para la funcionalidad de Pick'em:
- Las cuentas pueden votar por 1 streamer y el voto solo puede ser de 1 cuenta.
- Los streamers podrán recibir multiples votos, pero cada voto va para 1 streamer.
Para permitir que los viewers también jueguen:
- Necesitaré una tabla de viewers para registrarlos en alguna parte.
- Además relacionar estos viewers a las cuentas; ya que deberán registrarse y solicitar ser parte del evento.
- Se relaciona a los streamers para que estos acepten la solicitud de los viewers.
- Estos viewers también tendrán cuentas del juego a las que se le debe dar seguimiento en el sistema.
Para saber quien se enfrenta a quien:
- Agregué una tabla de Matches y así poder mostrar un vs entre los streamers
Estrategias
Websocket
Para mostrar los votos me gustaría implementar websocket y mostrar en tiempo real el cambio, seria primera vez y es un deseable.
Webhook
Para saber si ocurren ciertos eventos, Twitch provee una subscripción llamada EventSub, de lo que he leído en la documentación es un clásico webhook.
¿Qué es un webhook?
Tu registras en Twitch una ruta de tu api con ciertos parámetros, twitch al ocurrir el evento consume esa ruta que le diste y a partir de eso te mantienes suscrito.
En este caso me subscribiría al momento que un streamer inicia la transmisión o la cierra. Para una extensión de chrome hice polling y fue un infierno xD
API Polling
Lastimosamente la API de Riot no tiene webhooks, por lo tanto toca hacer Polling y enfrentarme al problema del Rate Limit. Pero ya tengo experiencia justamente con esta API, gracias a My LOL TierList:
Para hacer API Polling se debe contemplar el trigger y una estrategia de rate limiting. El trigger en este caso debe ser un scheduled job (aka cron job).
Scheduled Job
Como en este caso planeo utilizar serverless functions, por ser NextJS no puedo dejar un job corriendo eternamente revisando la hora.
Por lo tanto, debo utilizar algo externo y justo Vercel da una solución gratuita dentro de los Github Actions (ojalá sea suficiente).
VercelEstrategia de Rate Limiting
Las estrategias que trataré están bien explicadas en el siguiente artículo, es buenísimo:
Nikrad MahdiSoftware Engineer
Yo anteriormente en My LOL Tierlist, guardé la fecha en que realizaba las llamadas y sin darme cuenta hice una combinación rara entre "Fixed window counters" y "Token bucket".
En este caso ya no es el cliente quien realizará las llamadas, sino el job; por esta razón, no es necesario algo tan complejo:
- Token bucket es aceptable pero leyendo veo que puede haber un choque entre la lectura y escritura, no planeo utilizar redis solo para este problema, también quisiera reducir las consultas a la base de datos.
- Fixed window counters creo que sería la opción perfecta; ya que reduce el uso de la memoria y su desventaja de ser llamadas muy variables no me afecta. El job lo controlo yo y no es un cliente malicioso.
Último puntos y alcance
- Limitaré el sistema a saber si los streamers están jugando uno contra el otro, pero no indagaré dentro de los matches; ya que serian muchas mas consultas al API de Riot, lo que provoca acercarme más al límite de consultas.
- Solo se podrán obtener los clips más destacados uno por uno; ya que el API de Twitch así solo lo permite. La verdad no tengo ganas de agregar complejidad en ese punto.
