Procesos en Background con Sucker Punch en Rails
Contenido del curso
Carlos Esteban León Pinilla
Johan Tique
Profesor
Manuel Alejandro González Cabello
Manuel Alejandro González Cabello
¿Por qué usar el sistema de jobs que se plantea en el curso en vez de usar una tarea y programarla con la gema whenever para hacerlo como cron job? ¿Es lo mismo?
Hola Carlos, es una muy buena pregunta, y debemos remitirnos a el contexto donde de forma natural estos sistemas pueden ser usados
TL;DR los cron jobs (extraído del mundo unix) son procesos generales (independientes) que se ejecutan en segundo plano que normalmente lo hacen con una periodicidad definida (por hora, diario, semanal, etc), Los background jobs de Rails son procesos con conciencia de la aplicación que naturalmente ejecutan tareas asíncronas y que dependiendo de su gestor, te permitirá tener un control granular de su ciclo de vida y ejecución.
En la clase planteamos un ejemplo muy simple, de hecho, Rails usando ActionMailer ya nos provee con un método propio para hacer envíos programados de emails.
Abordemos el tema de los Cron Jobs en función de Whenever, esta gema te permite desde el schedule.rbconfigurar de forma plana tareas que se ejecutan periodicamente en tu instancia o servidor, esta gema hace una configuración de cron desde su DSL, y te permite correr cualquier comando externo que tu sistema operativo y tus roles tengan permitido correr, así que naturalmente estos procesos no tienen conciencia de tu aplicación y su ciclo de vida es gestionado por el sistema operativo acorde a la forma como instancies tu proceso, de esta forma, para correr tareas de Rails con whenever normalmente tendras que usar Rake para poder cargar y usar tu aplicación.
Por otro lado, los Background Jobs de Rails son procesos que nacen como respuesta de un evento asíncrono (no programado, que ocurre bajo demanda) que en la mayoría de las veces es causado por un actor externo a tu sistema y que además en muchas ocasiones podría demandar gran uso de recursos o de tiempo. Estos procesos son gestionados por un gestor de procesos del mundo de Ruby que tiene conciencia natural de tu aplicación, que ademas suele proveerte un control granular de la ejecución de los procesos en términos de estado, reintentos, rendimiento, recurrencia, control de excepciones, control de lotes y muchas cosas más.
Al final, puedes ver que ambos tienen un ambiente de ejecución predilecto, y aunque puedes forzarlos a los dos a hacer tareas muy similares ambos te exponen fortalezas para escenarios específicos.
Hola profe tengo una cosulta. No lo gro hacer que funcione el envío del email usando el job. Sin emabrgo si cargo cualquier tarea en consola y llamo al job desde la consola hace el envío sin problema.
Encontré el problema. Me di cuenta que me arrojaba el siguiente error: ActiveRecord::RecordNotFound Couldn't find Task with 'id'=70
Por lo que por alguna razón el job se estaba intentando ejecutar antes de que la tarea se guardara en la base de datos. Lo que hice fue cambiar el callback por un after_commit para asegurar que la tarea ya hubiese sido persistida al momento de llamar al job y funcionó.
