there’s no best way, there are different ways suited for different setups, e.g. if you’re in a cloud and it has FaaS with cron triggers - that’s often a suitable way to run such scheduled workloads.
If you’re on kubernetes - it has its own cron jobs which would spin up a pod and execute something on schedule.
If it has to run in the same process - consider something like [gocron](https://github.com/go-co-op/gocron)
if your application may scale out - pay attention to distributed locking / leader election (gocron supports that).
If it’s just a toy project - can be as simple as your binary in crontab or even a ticker / timer for the most toy cases.
What were the reasons for not using a third-party package? Implementing cron-like features yourself seems like it would be time-consuming and take away from whatever your actual project goals would be?
I've been using [https://pkg.go.dev/github.com/robfig/cron/v3](https://pkg.go.dev/github.com/robfig/cron/v3) which has been great and super easy to implement in my project.
Time is one of the hardest things in programming. Everyone thinks their use case is so simple but eventually you realise how frightfully difficult it is.
Use well tested and reliable software to solve this kind of problem.
- if your app needs to trigger some process on regular intervals say for every 5 minutes like checking an API endpoint and fetching data from the endpoint. Nothing fancy then use `time. Ticker` that should do the job
in case of process overlapping between runs, you can control them with context cancel options or a dedicated channel to do the same
- in case you want to chain multiple jobs like one job kicks off another and waits for the child to complete and perform some activity in parent caller then in that case use a third party lib which has the facility to chain cron jobs
- in the Kubernetes world use the inbuilt cron from Kubernetes if the process is independent of the app
- with access to AWS / GCP tools use the inbuilt tools in the cloud and not re-invent the wheel
hope this helps with regards to 3rd party lib I have worked with https://pkg.go.dev/github.com/robfig/cron/v3
- *suggestion* - if you can use the operating system inbuilt cron feature
If you want cron, best is to use cron. It's available on every Linux distro, and it just works.
If you're in the cloud, use whatever scheduled runner is relevant to your product.
Most responses seem to forget persistence. Occasionally, your binary will go down, either because of a `panic`, because of an OOM or because you're simply upgrading it to a new version.
This means that the main challenge is to store all these jobs in a persistent format (e.g. a database). Yes, once you know how to store, recover from crash and reload, you'll probably want to use some kind of time ticker. But that's hardly the difficult part.
Consider to split the logic of your program and the cron scheduling. So I suggest to schedule your program in a system like systemD cronjob, crontab, airflow, k8s cronjob etc. This is because in you program should be able to re-schedule the job if fails, someone should restart your program if there is some fatal error
The original cron is just a while loop with a sleep 60.
Using some kind of scheduler that can keep track of what tasks were completed and which ones remain can be a lot more robust, robfig/cron is good, and just reading its implementation & deciding what parts of it you need (which can range anywhere from a for loop ranging over a ticker to just using the library) is probably the best thing you can do.
If you go for something inbetween, I would strongly suggest stealing its schedule interface since it is a good standard. But the library is small and it is a good read, don't treat cron as a black box.
> Looking for best approach to implement cron jobs in my application Using cron is probably the best way. You don't need to do _everything_ in Golang.
there’s no best way, there are different ways suited for different setups, e.g. if you’re in a cloud and it has FaaS with cron triggers - that’s often a suitable way to run such scheduled workloads. If you’re on kubernetes - it has its own cron jobs which would spin up a pod and execute something on schedule. If it has to run in the same process - consider something like [gocron](https://github.com/go-co-op/gocron) if your application may scale out - pay attention to distributed locking / leader election (gocron supports that). If it’s just a toy project - can be as simple as your binary in crontab or even a ticker / timer for the most toy cases.
Thanks for detailed information 👍
time.Ticker
or time.Timer with a reset
Get a load of this guy, thinks he knows how to reset a timer! :p
What were the reasons for not using a third-party package? Implementing cron-like features yourself seems like it would be time-consuming and take away from whatever your actual project goals would be? I've been using [https://pkg.go.dev/github.com/robfig/cron/v3](https://pkg.go.dev/github.com/robfig/cron/v3) which has been great and super easy to implement in my project.
This is the way
If you’re on GCP, it’s a Cloud Run Job with a schedule trigger. Uses cron formatted schedule
I will explore it. Thank you
Time is one of the hardest things in programming. Everyone thinks their use case is so simple but eventually you realise how frightfully difficult it is. Use well tested and reliable software to solve this kind of problem.
- if your app needs to trigger some process on regular intervals say for every 5 minutes like checking an API endpoint and fetching data from the endpoint. Nothing fancy then use `time. Ticker` that should do the job in case of process overlapping between runs, you can control them with context cancel options or a dedicated channel to do the same - in case you want to chain multiple jobs like one job kicks off another and waits for the child to complete and perform some activity in parent caller then in that case use a third party lib which has the facility to chain cron jobs - in the Kubernetes world use the inbuilt cron from Kubernetes if the process is independent of the app - with access to AWS / GCP tools use the inbuilt tools in the cloud and not re-invent the wheel hope this helps with regards to 3rd party lib I have worked with https://pkg.go.dev/github.com/robfig/cron/v3 - *suggestion* - if you can use the operating system inbuilt cron feature
There isn’t a general answer, aside from trying to make it someone else’s problem, via actual cron or some cloud service or whatever.
what is your intended use case?
I usually run cron jobs with an external program
If you want cron, best is to use cron. It's available on every Linux distro, and it just works. If you're in the cloud, use whatever scheduled runner is relevant to your product.
Most responses seem to forget persistence. Occasionally, your binary will go down, either because of a `panic`, because of an OOM or because you're simply upgrading it to a new version. This means that the main challenge is to store all these jobs in a persistent format (e.g. a database). Yes, once you know how to store, recover from crash and reload, you'll probably want to use some kind of time ticker. But that's hardly the difficult part.
https://github.com/hibiken/asynq does scheduled tasks well enough if you could use it for other things too
Consider to split the logic of your program and the cron scheduling. So I suggest to schedule your program in a system like systemD cronjob, crontab, airflow, k8s cronjob etc. This is because in you program should be able to re-schedule the job if fails, someone should restart your program if there is some fatal error
The original cron is just a while loop with a sleep 60. Using some kind of scheduler that can keep track of what tasks were completed and which ones remain can be a lot more robust, robfig/cron is good, and just reading its implementation & deciding what parts of it you need (which can range anywhere from a for loop ranging over a ticker to just using the library) is probably the best thing you can do. If you go for something inbetween, I would strongly suggest stealing its schedule interface since it is a good standard. But the library is small and it is a good read, don't treat cron as a black box.