Esta es la continuación del post anterior:
Anteriormente planteaba una estructura basada en múltiples servicios y componentes como se muestra a continuación:
Como se puede apreciar, todo pasa por un nodo principal que es el servidor websocket, incluso si no era necesario como las consultas del Twitch API.
Leyendo encontré que Firebase encaja muy bien en mi proyecto:
Cloud Firestore
Es una base de datos en tiempo real que provee soluciones para atender todo el tema del websocket que planeaba diseñar desde cero, por lo tanto esta es mi mejor opción; además se integra a otros servicios.
Si el dispositivo se desconecta, guarda en el dispositivo hasta nuevamente conectarse; con esto soluciona múltiples problemas al trabajar con el túnel de websocket.
Reemplazaré Postgres, Redis y Prisma por este servicio.
Firebase Authentication
Es una solución que brinda autorización y autenticación, conexión con múltiples redes sociales, se integra a Firestore y maneja la sesión en el dispositivo. Permite igual incluir servicios que no se encuentran listados (en este caso Twitch).
Reemplazaré NextAuth por una conexión directa a Firebase (por el momento)
Cloud Functions
Estos Cloud Functions son serverless functions, como Azure functions, Lambda functions, que ejecutan lógica junto al Firestore.
Justo aquí realizaré la lógica de API Polling y Scheduled Job; me aseguré que todo lo que necesito sea posible:
Debo realizar ciertas modificaciones para tener cuidado con el performance y reducir las dependencias.
Pensamientos Finales
No me agrada mucho ser totalmente dependiente de lo que me ofrece Firebase, pero son más ventajas que desventajas.
No tenía idea de todo lo que conlleva el patrón utilizando un servidor websocket y Firebase lo soluciona.
Tenía pensado terminar de integrar Firebase en el proyecto, pero ha sido una semana difícil... ¡Será para la próxima!
