I can understand the use-case it was built for but would argue that there is a need for time-based triggers of Netlify Functions as it’s in my opinion the only missing piece of a complete JAMstack architecture.
Assumption
Assume my goal is to eliminate completely any backend server in exchange for a statically hosted front-end, serverless functions providing all traditional server-side abilities, and persistence provided as a hosted service for me, then where do scheduled jobs fit in this architecture?
Consider
As more and more is possible on the client side (rich SPAs), and more and more backend features are made serverless (FaaS, PaaS, RDS, Graph.cool | Prisma | Hasura hosted), the traditional backend server goes away. One of these backend servers is where we would traditionally run time based tasks scheduled with cron.
Example Use-cases
Scheduled jobs are a necessary part of many application architectures but let me mention a few that come to mind from our requirements:
- periodically tracking active shipments with UPS since UPS does not offer an event-based solution
- alerting when an expected state change has not happened after a set amount of time (the lack of an event + duration = new event)
- action that must happen on a specified amount of time prior to a future state change which will happen on a schedule (preparing a shipment for an order fulfillment in the future)
These small bits of logic fit into a lambda based micro-service architecture well but miss a clean and easy way to trigger them on a schedule without leaving the Netlify platform.
Solutions
- Zapier (pricey if all you’re doing is scheduling an HTTP invoke of a Netlify Function)
- IFTTT (free)
- CloudWatch (free)
- EasyCron (pricey for just job scheduling)
These all provide viable solutions, you are correct in mentioning them, but they don’t easily fit into the CI/CD flow on Netlify. I’m not arguing that if Netlify doesn’t provide this functionality, the community is left without because the above solutions work fine albeit with trade-offs regarding deployment. Rather I’m simply suggesting that the added complexity of leaving, the otherwise complete, Netlify stack for something as trivial as setting up a scheduled invocation of one of the Netlify Functions could be removed with a configuration option on Netlify itself. A convenient way to implement this would be a new section in the toml file as @omonk suggested. On the Netlify side this toml entry could simply be translated into a CloudWatch scheduled event triggering the Lambda that backs the Netlify function specified.
Thanks for taking the time to read all this!