Adding the cognitive burden of "serverless" and/or lambda just to schedule seems to complicate something that isn't very complicated. Its almost like an invented problem.
That said, long live this static site generator movement.
I'm betting this movement will continue to grow which is why I'm bootstrapping https://www.remarkbox.com (comments-as-a-service)
This project came out of the need from our content team needing to publish content late at night and when people are out of office =)
Check out the code https://github.com/serverless/post-scheduler/blob/master/han... this serverless service is just 2 functions that get deployed. It's a set it and forget it service =)
I suppose my original perspective was coming from a one-person operation.
1. I can keep track changes with git 2. I can host them on Github pages for FREE 3. I own the content 4. More flexible
In fact I've been really annoyed with all the boilerplate code and extensions I need to deal with in order to have a "usable" workflow set up, I almost thought about moving back to free blog services like medium, tumblr, wordpress, etc. but the only reasons I can't are the ones I mentioned above.
Wordpress is simple from an end user perspective.
Services like medium and tumblr hide the complexity from its users. Its a trade off.
Wordpress and co are easy, but they're fundamentally much more complex than static sites.
Jekyll is quite simple, but it can be hard to use in comparison.
After all, you can argue that the publishing-side stack is anyway very complex: it includes e.g. the Github UI, if one makes edits using the Github UI.
Or use a CI cron running daily?
In theory yes. I could provision a new function with an exact cron schedule to run once and then tear itself down.
In practice, this is a lot of extra logic to write to achieve this and would also potentially make own AWS account rather messy.
The hourly cron runs about 720 times a month which is far below the 1,000,000 free invocations that lambda provides under their free tier.
1. fire off AWS Step function on new post to S3 bucket
2. read delay / schedule time in metadata from (assumable) markdown post
3. trigger AWS Step Function using the Wait State defined based on read value from 2.
4. As part of Step Function: After Wait State -> Execute Lambda to publish post.
Note: 3) requires setting variable time in Wait State based on environment. Haven't read up so don't know if that's possible, but guess it should be.
To which I don't understand the appeal of serverless besides having no servers lol.
So it's up to you where your code runs =)
And paying Amazon for the privilege of doing so!
Well done... golf clap
> The hourly cron runs about 720 times a month which is far below the 1,000,000 free invocations that lambda provides under their free tier.
This entire service (the 2 functions & 1 dynamo table) should run well under the AWS free tier. see https://aws.amazon.com/free/
Edit: My backyard is filled with old rocket ships, so I am an expert on this subject :-)
If you host using Netlify you can create a build hook to just curl. You could even use Cronitor for a free cron.
Although in my case, I host my Jekyll based site on my own server and just run a daily build via local cron.
The workflow to post anything (present or scheduled) is nothing more than a single git push to get the new content on the server.
It's as simple as can be. #serversforlife
