How a Cache works with Redis (using Nodejs)

[@kikecastor]

Excelente, gracias Fazt, sigue así, eres chingón, me uni a tu canal en dónde tanto he aprendido, quiero regresarte una parte de todo lo que he aprendido, muchas gracias!

[@solarluiso10]

jejeje en lo que entro y salgo del baño ya este tio se saca un proyecto con node, express, redis, docker y hasta se sale del codigo para explicarte. sé que hay un trabajo por detras de cámaras pero muy oportuno y al grano. muchas gracias de parte de todos.

[@JoseRafaelJM]

Impresionante que hace dos días estaba buscando algo sobre node y redis y llega esto! Gracias Fazt!

[@danlukae1166]

Graciaaaas broo, estuve viendo tu vídeo de hace tres años usando redis pero estaba algo desactualizado:' ahora con este vídeo ya logré implementar redis

[@Fermx95]

Siempre que veo sobre algún tema interesante ; después veo que ya subiste un video sobre eso , todo un crack

[@mishelrodri]

Vales oro Fazt ✨ gracias crack!!!!

[@Hackeandomivida]

gracias mi crack, justo necesita entender redis

[@Dieghoatc1]

Que locura, parece que Fazt lee nuestros pensamientos. ¿Quieres implementar algo? pum video de fazt subido hace poco jaja. Pto Crack eres fazt.

[@Weagle1337]

15:42, muy util redis, hace poco hice una cache para la sesion y permisos, en cada request usaba la cache, pero si el admin cambiaba los permisos, borraba la key para que el middleware trajera y setear los permisos de nuevo en la key y asi reflejar los nuevos permisos al instante en la siguiente request

[@arnulforuizsanchez1818]

Al fin, necesitaba esto jaja, estaba pensando en implementarlo

[@mastermaster153]

supongo que cada cierto tiempo debemos actualizar la información almacenada en reddis, no? porque es muy probable que la informacion cambie con el tiempo

[@astrixwr5662]

Gracias Fazt, justo en mi trabajo hay esta necesidad y queria implementar algo similar

[@emmanuelbarba2567]

Una duda ¿en aplicaciones móviles cómo funciona jwt? En estas aplicaciones nunca me piden iniciar sesión de nuevo para generar un nuevo refresh token.

[@darkkinggamesyt6463]

Misma consulta

[@usuarioaleatorio336]

al iniciar sesión se genera el wjt y tu front lo tiene que guardar localmente en una cookie, o localstorage, pero tiene que quedar a nivel local. luego tu front al iniciar la aplicación, primeramente tiene que preguntar si hay un jwt alojado localmente (en cookie o localstorage), y debe preguntar si no existe token, seguir el flujo de pantalla de login, en caso contrario, si hay un token, no se pinta el login, sino que se envia el token a un endpoint de backend, que lo validará, y si todavía es válido, debe autorizar al front-end, para que levante el aplicativo con la sesión de ese token, y si no es válido dar una respuesta indicándole al front que vuelva a al flujo de inicio de sessión

[@darkkinggamesyt6463]

@@usuarioaleatorio336 pero eso funciona en web. Pero móvil?

[@emmanuelbarba2567]

@@usuarioaleatorio336 gracias, es que ese flujo es el que tengo entendido que se tiene que seguir pero en las aplicaciones móviles como instagram nunca me piden volver a iniciar sesión entonces no sé si el token de refresco no tiene tiempo límite o utilizan otra forma de autenticar.

[@usuarioaleatorio336]

@@emmanuelbarba2567 emanuel, sí he visto algo así, en cierta plataforma, al final habia que hacer refresh con las password de usuario, aunque la doc decia que el refresh según en las indicaciones, no retorna el refresh token. saludos y suerte

[@iamlagex]

Muchas gracias! :D

[@SwiftHumor]

mi pregunta es como saber cuando actualizar redis porq los datos en una aplicación normal aunque no cambien con frecuencia pueden cambiar

[@404-not-found-service]

Gracias fazt!

[@angelffg]

Genial Fazt, está genial como todos tus videos! FELICITACIONES!!!! Pregunta por favor: Podríamos ver un ejemplo donde se verifique si los datos han cambiado en la DB y de esa forma decidir si tomar los valores de redis o de la DB ? Eso me imagino que podemos controlarlo con una tabla que guarde el datetime de la última actualización a la tabla de la DB y que realice la pregunta previo a decidir si buscar en redis o en la DB. Un detalle con el ejemplo del video: --------------------------------------------------------- Si un usuario #1 ejecuta la ruta /characters/1 se guardará en redis el Key id con el valor retornado, eso está bien, pero si luego otro usuario de la misma restapi ejecuta /characters/2, la restapi tomará los datos del ID #1, por lo que el save en redis de ese Key, debería estar compuesto por ID+Número. Un abrazo y por favor sigue adelante. El contenido del canal es muy bueno (y)

[@jahbless8244]

No deberia porque id sera el valor pasado por parametro, y cambiara entre 1,2,3 etc. ya que client.get obtendra el valor del id, y este al no existir no hace el early return.

[@angelffg]

@@jahbless8244 Estimado, tienes razón. Arriba en mi mensaje original les pido disculpas y hago la correción de mi error. Gracias por participar.

[@angelffg]

Pido disculpas a la comunidad y en especial a FAZT, pués en mi comentario anterior dije que existía un detalle en la ruta: /characters/:id , pero fue un error, porque en la función, cuando FAZT hace client.set() , éste recibe el VALOR de la variable ID la cual se extrae del Body y de req.params. Ese valor es el ID del personaje (1, 2...etc) y en redis se guardará el par Key/Value de la siguiente forma: "Valor del ID pasado como parámetro" : "Datos del personaje" Disculpen nuevamente mi error en la interpretación del código. Pensé que el Key/Value sería el siguiente: Key = "ID" Value = "Personaje solicitado", siendo ID siempre el Key, pero mirando el video nuevamente, observo que el Key es el valor del ID pasado como parámetro (1,2,3...etc) y no el string "ID". Espero haberme explicado. Gracias!

[@ArielManuelNaranjodelaCr-cm8jz]

gracias 🎉

[@twulfnt]

Gracias, justo necesitaba introducirme a Redis para hacer Queues, si puedes hacer un video también lo agradecería!

[@gabrielbarzola6874]

Todo genial pero lo mismatch poses lograr con in cache en memoria. Redis sirve cuando tenes varies instancias o queries persistir en case de que se reinicie el process

[@Sean17nl]

Gracias

[@rodolfolopezp]

Es solo para datos estáticos?. Que pasa con dinámicos?

[@comentsization]

tremendo¡¡¡

[@kohlod]

Muchas gracias por el tutorial, muy util y bien explicado. Solo tengo una duda sobre si tiene alguna version gratuita o si tiene algun costo

[@Max-nm4bu]

Buen video Fazt, podrías hacer algún video con la API de chatpdf por favor, saludos.

[@RicardoNotFound]

muy buen vídeo! ¿Qué tema de vscode usas en el video?

[@FaztCode]

Este Se llama Tokyo night Dark

[@jeanrodriguez6645]

un crud hecho con laravel para una api con redis sería uff. Excelente vídeo Fazt, me aclaraste esa duda acerca del uso de Redis :)

[@srfrank]

Alguien sabe el nombre de la herramienta para crear conceptos/diagramas que aparece en el video? Gracias!

[@srfrank]

Si no me equivoco, es esta: excalidraw

[@gamuro6977]

Recomiendan almacenar jwt en redis?

[@MRPinas2100]

Gracias amigo Fazt, una pregunta que me queda, si redis cachea en la ram ¿eso se esta haciendo en el cliente si es externo? me explico, imaginando que yo consulto tu backend por medio de api ¿como optimiza las respuestas hacia mi frontend? o ¿para el tema del frontend o servicios aparte se debe mirar otros enfoques? De ante mano gracias.

[@mis2michis726]

Gracias Profe! Muy útil este video. Tengo una pregunta, en caso de consultar datos que no son fijos pero que cambian con mas o menos cierta frecuencia, como podriamos actualizar la data en redis? Habría que reiniciar el servidor o habria alguna otra manera de decir por cuánto tiempo estara guardado esa data en redis?

[@FaztCode]

En ese caso tienes la opcion de establecer un tiempo de Expiracion a lo que guardas, de esa forma venceria despues de cierto tiempo, y se volveria a guardar en memoria cache, o la otra forma es eliminando el dato de redis usando el nombre con el que se guardo :)

[@mis2michis726]

@@FaztCode Ah perfecto! Eso es lo que necesitba saber. Gracias!

[@yamilcastillo861]

Maestro!!!!!!!!!!!

[@masterblink1]

Gracias Fazt! Una consulta, que pasa si el registro cambia en la base de datos? como se actualiza en redis?

[@FaztCode]

Tienes la posibilidad de definir un tiempo de expiración para los datos que almacenas. Esto significa que, después de un período establecido, los datos se eliminarán automáticamente, y Redis los volverá a guardar en la memoria caché cuando se soliciten nuevamente. Otra alternativa es eliminar manualmente el dato de Redis cuando actualices o elimines algo en tu aplicación, utilizando el nombre con el que se almacenó. Sin embargo, este enfoque puede añadir algo de complejidad al realizar las consultas. 😊

[@masterblink1]

@@FaztCode Ok me queda claro. Gracias Crack!

[@rodolfolopezp]

Es factible usarlo con NEXTJS 15 o con el swr de next es suficiente?

[@raulgabrielhacho9231]

Como hago un sass multiinquilino en nestjs y react. Ayudaaaaaaaaaa

[@tomaswilliams900]

Y en el caso de que me retorne lo que guardo en cache, que ocurriría si mi data en algún momento se le añade o quita algún dato, me devolvería lo que ya guardo en cache por ende me devolvería data antigua. Como se solucionaría en ese caso?

[@FaztCode]

Es correcto lo que mencionas, te devolveria datos antiguos, y la idea de la cache es usarlo para datos que no varian mucho, aun asi, tienes la opcion de establecer un tiempo de Expiracion a lo que guardas, de esa forma venceria despues de cierto tiempo, y se volveria a guardar en memoria cache cuando lo vuelvas a solicitar, y la otra forma es eliminando el dato de redis cuando actualizas o eliminas algo, usando el nombre con el que se guardo, aunque esto añade mas trabajo al momento de hacer consultas :)

[@usuarioaleatorio336]

@@FaztCode muy buena gracias por enseñar

[@yerefc]

Oye, Fazt, me trae curiosidad cómo funcionan las aplicaciones multiplataforma. Por ejemplo Unity que te permite exportar un juego a distintas plataformas ¿Cómo funciona eso por dentro? Un saludo ❤

[@arnulforuizsanchez1818]

Duda, que diferencia hay de que la primera persona consulte la API y lo guarde en un arreglo en el servidor, para que cuando vuelvan a solicitarlo comprobar si el arreglo no esta vacío, si esta vacío preguntar a la API y si no esta vacío hacer que devuelva el arreglo sin volver a preguntar a la API? (Es lo que estoy implementando)

[@freestyleloven8762]

El problema sería, que si tú servidor se para por cualquier motivo, perderás la información que tienes en el arreglo, mientras que redis no depende de tu servidor, por lo tanto la información seguirá en memoria, también en caso de que tengas corriendo múltiples instancias de tu servidor , todas pueden acceder a la información almacenada en redis y no como en el caso contrario que cada instancia tendría su propio arreglo

[@arnulforuizsanchez1818]

Cuando dices múltiples instancias te refieres a una metodología de Microservicios? Entonces eso no pasaría si es el sistema es un Monolito?

[@jibaru]

Incluso los monolitos pueden tener multiples instancias, cuando se escala horizontalmente. Y si usas solo una instancia, tambien podrian ocurrir race conditions entre distintas solicitudes, pero solucionable con un candado.

[@usuarioaleatorio336]

en esencia el concepto es el mismo, los datos de caché estarían e la memoria ram del servidor y la respuesta sería sumamente rápida. de hecho redis es una bd in memory, es decir que tiene la data desplegada en ram en forma indexada y previendo accesos de respuesta rápida por lo que la respuesta es más rápida que una lectura a disco en una query a la bd (aunque las bd normales también trabajan parcialmente in memory, pero depende cual bd), por lo tanto tu solución puede funcionar. Como dijo freestyleleloven8762, no tendrías persistencia y tendrías que cargar nuevamente los datos en tu arreglo en memoria al reiniciar el servidor, o tendrías que implementar la persistencia en tu solución, ya ahi talvez el trabajo implicado justifica mejor poner redis y no implementar eso...pero si para tu necesidad es suficiente, puedes manejar el arreglo y evitar redis y talvez licencias, depende de ti....y con instancias se refería a varios servidores con la misma copia del programa, atendiendo peticiones, seguramente ubicados detrás de un Balanceador de Carga o algo así como si tuvieras varios servidores con distintos aplicativos que lean datos comunes en el mismo redis

[@mexicandevelopers6469]

Acios v: