So I developed a system with Nest.js which is able to create a dynamic cronjob from a user's input in the frontend application, I store this data in my database and at the same time I create the job in the server with the Dynamic schedule module API. Today I was wondering what would happen to my cronjobs if my server was shutdown or if it restarted itself, since my jobs aren't declarative and they are created at runtime I think that maybe when my server starts I should create the cronjobs again? I'm not sure if this get stored in memory or something since it's not in the documentation.
My concern, in fewer words, is:
Should I recreate my jobs using the information from the database once the server starts itself? Why yes or why not?
Once the server restarts, you'll have to restart your CRON tasks.
The reason for this is that your NestJS application is not really adding CRON expressions to a crontab on the machine but instead scheduling and running these tasks in a CRON expression capable task runner (package example: node-cron)
Once the server stops, the scheduler (that runs on the same process) also stops.
You've mentioned you already store the tasks in a database, so you should be able to get the information you need to recreate the task on server init.
I assume you have a Service that handles CRON tasks and has access to the DB. Otherwise you can just create a dedicated one
You can modify it to implement the OnModuleInit interface and execute logic that would read all the existing tasks that should run and start them:
@Injectable()
class CronService implements OnModuleInit {
constructor(private readonly cronRepository: CronRepository) {}
/*
...
CRON IMPLEMENTATION
...
*/
private async restartSavedCronTasks(): Promise<void> {
// get date from DB and start all relevant tasks
}
async onModuleInit: Promise<void> {
await this.restartSavedCronTasks();
}
}
The answer is yes, you should recreate the cron jobs after the server restarts. It's best that once the user's creates the cron job, you'll store it in the DB or use the DB you already use for Frontend.
In general, you could have two levels of persistence of this data in case of necessity.
Scenario 1
You very seldom restart your servers. In this case, store to something persistent like a json file in an s3 bucket (not public) or to a sql or mongo database if you have it connected.
Recreate the "unhandled" or relevant cron jobs on server warmup.
Scenario 2
You often restart your servers/services. In this case, perhaps store to an in-memory db like Redis as well as a more persistent type (in case your Redis db falls and you need to repopulate it - provided that this data is important).
Recreate the "unhandled" or relevant cron jobs on server warmup.
Storing to Redis in general instead of storing in-memory on a specific server instance will also allow your general architecture to be more scalable as a different server can read from Redis as well (same "source of truth")
I hope this helps you plan your architecture accordingly :)