Suggestion: add note that `staticman.yml` needs to be hosted, not just in repository root

[clairity]

i realize this is a corner case, and probably very obvious to devs/maintainers, but i got stuck on it, so i'm making a documentation request in case others run into this problem.

basically, i created an empty github repository for local testing of the staticman comments lifecycle, but put no files in it, thinking i just needed to see how the commits/pull requests came through (but otherwise configured properly^[1]). needless to say, that doesn't work because staticman (deployed to a free heroku dyno) looks for the staticman.yml file in the hosted (not local) repository.

that makes total sense in hindsight since (heroku-hosted) staticman won't otherwise have a config file to reference, but i didn't realize it until i updated staticman to the recent #346 commit that provided a more descriptive error (404 for the staticman.yml file).

the doc change could be as minimal as this (in italicized bold) to the Site Configuration section of the readme:

Staticman will look for a config file in the hosted repository (on github, gitlab, etc.). For the deprecated v1 endpoints, this is a _config.yml with a staticman property inside; for v2 endpoints, Staticman looks for a staticman.yml file at the root of the repository.

once i created the staticman.yml file on github (plus creating a master branch as part of that), comment posting started showing up in the repo (🎉).

[1] much thanks to these resources for making setup and configuration easy!

• Performance Matters @travisdowns
• Spinning Numbers @willymcallister
• Made Mistakes @mmistakes

[lionxlife]

omg... I've been trawling the internet re gatsby and staticman because I kept getting {"success":false,"errorCode":"GITHUB_READING_FILE"} issue... was trying all kinds of shenanigans until I came across this!! Wow, thanks. After I committed my files and pushed it worked. Thanks so much!! Not sure if anyone will action this since apparently the author has gone MIA but yeh, glad it's here for people who have issues.

[travisdowns]

@lionxlife - the original author isn't involve any more, but @alexwaibel is still here and active it seems. Since this is a small doc change, and uncontroversial, it seems likely that a PR might be accepted? What do you think @alexwaibel ?

[alexwaibel]

I agree, this is definitely something we can clarify better in the documentation. Revising documentation is one of the higher priority items on the agenda lately. @shaftoe has been doing a bit of work on that front and I'm sure could incorporate something to clarify this issue.

[shaftoe]

@alexwaibel I'm sorry to disappoint but I'm not planning to invest much of time in Staticman develpment at the moment, I gradually lost interest in the project and to be honest at this point I'm thinking about baking my own solution from scratch.

I know it will never be as popular as Staticman but I think what I need (a replacement for Disquss for my Hugo website, no more no less) is not that hard to achieve with in a serverless fashion and I think I could settle with that.

If I'll ever decide to allocate some effort to actually do that, it will be an open source project anyway so everyone welcome to use and contribute.

To elaborate more on the why, technically speaking: I believe that nowadays, for a stateless and infrequent usage pattern like the comments of small/medium traffic websites, there's no real need for keeping a server running 24/7 (even if it's a free Heroku dyno) when you get plenty of FaaS free execution time from AWS, GCP, Azure and the like. Something like a few AWS Lambda backed by an API HTTP Gateway should do the trick.

I wish Staticman all the best though and I hope the project will find a way to properly get the love it deserves 😉

[travisdowns]

To elaborate more on the why, technically speaking: I believe that nowadays, for a stateless and infrequent usage pattern like the comments of small/medium traffic websites, there's no real need for keeping a server running 24/7 (even if it's a free Heroku dyno) when you get plenty of FaaS free execution time from AWS, GCP, Azure and the like. Something like a few AWS Lambda backed by an API HTTP Gateway should do the trick.

Eh? Heroku is more or less serverless, and it has a free tier. It's stateless and spins up dynos on demand. The dyno keeps running for some period after being spun up, but of course serverless providers do that too (even if they don't document it).

At least in the way I've used it I've never paid a cent and it acts like serverless.

Not to discourage you from doing your own thing though, I'm interested to see how it works out!

[shaftoe]

Sure, currently my Staticman instance is actually run by Heroku, I also have an Ackee instance on Heroku though and together they are topping the free tier. On the other and I'm pretty sure that with AWS I could host a medium-traffic instance and stay comfortably in the Lambda free tier.

Another downside of Heroku is latency: it might take a few seconds to revive the dyno once a new comment is created, and if you keep the dyno running all the time with some kind of monitoring to avoid sleeping you'll soon run out of the free hours as well.

So, my feeling is that if you want to have something that resembles a production setup you really need to pay Heroku for that, which is more than fair and that's what I'd recommend today if you're going to deploy Staticman.

More in general I believe I need only a limited subset of what Staticman is currently offering and it should be easier for me to develop just that compared to understanding the codebase and trying to fit it to my needs.

I've not dug much into the matter yet though but something like Probot might do the trick without much of effort.

@travisdowns I'll keep you updated than and if you'd like to throw in ideas/feedback you're more than welcome!

[travisdowns]

Another downside of Heroku is latency: it might take a few seconds to revive the dyno once a new comment is created, and if you keep the dyno running all the time with some kind of monitoring to avoid sleeping you'll soon run out of the free hours as well.

Yes, this is definitely a downside. I usually see 10-20s of latency before a comment is accepted, if the dyno is asleep. I've considered adding a little bit of javascript that would poke Heroku once the user starts adding a comment (or perhaps once they've completed the reCAPTCHA) to eliminate this.

So, my feeling is that if you want to have something that resembles a production setup you really need to pay Heroku for that, which is more than fair and that's what I'd recommend today if you're going to deploy Staticman.

Yeah, maybe? Depends what you mean by "production", but I definitely feel that staticman is useful for low-traffic blogs (like mine) and here Heroku works fine and the free tier is enough. I'm not against paying, but in practice there is a large difference between $0 and even $1 a month or whatever: needing to add your payment details, keeping everything up to date, having the worry that a small misconfiguration or a malicious user might cause your bill to skyrocket, etc.

So I think free tier is a valid use case. BTW, is the AWS Lambda free tier indefinite or for one year only?

I didn't know that paid Heroku tier was the current recommended way. Personally I recommend people use the free tier first.

I'll keep you updated than and if you'd like to throw in ideas/feedback you're more than welcome!

Thanks!

I'll probably stick with staticman since I've already expended a lot of energy to get it working, but I'm always interested to know what else is going on out there.

[lionxlife]

I was going to ask too if there's a newer and better way to do this having finally implemented it just now. Thanks for clarification. I use staticman with gatsby and I did notice the many seconds delay in getting a submission response, but thought I could handle that elegantly with react so no issues for me. The pros of a simple setup and full data control is still a big winner (granted you do have to hunt a little for docs and examples).

There's a bunch of unofficial, free bots that if we could list in the instructions, it would be really simple to get this running. In which case I wouldn't mind writing that instruction page, however we might run into the same problem eventually of the free bot hitting API limits.

[shaftoe]

Yes, this is definitely a downside. I usually see 10-20s of latency before a comment is accepted, if the dyno is asleep. I've considered adding a little bit of javascript that would poke Heroku once the user starts adding a comment (or perhaps once they've completed the reCAPTCHA) to eliminate this.

It sounds like a smart workaround, I didn't think about that but it could work.

Yeah, maybe? Depends what you mean by "production", but I definitely feel that staticman is useful for low-traffic blogs (like mine) and here Heroku works fine and the free tier is enough. I'm not against paying, but in practice there is a large difference between $0 and even $1 a month or whatever: needing to add your payment details, keeping everything up to date, having the worry that a small misconfiguration or a malicious user might cause your bill to skyrocket, etc. So I think free tier is a valid use case. BTW, is the AWS Lambda free tier indefinite or for one year only?

Sure, nothing beats free ever. I agree being "production ready" depends very much on the circumstance: for a personal web site I might tolerate that latency but for some commissioned kind of work I won't consider that to be even close to a decent UX, so it would be "production ready" only when creating a comment doesn't take long and risking to lose the visitor/commenter because of the poor UX.

If we stick with what Heroku recommends, they say that the free plan is "ideal for experimenting with cloud applications in a limited sandbox", so it's obvious that according to them the free tier is not meant for "production" (i.e. non trivial) workloads. That said, if the Heroku free tier serves your needs, of course you should go for it.

On the other hand, cloud services have the same availability / QoS regardless of being billed because above free tier usage or not. Every cloud have different pricing/tiering models, but for AWS Lambda in particular there's an abundant amount of forever free Lambda execution time any account can leverage. You can find the details here.

I'll probably stick with staticman since I've already expended a lot of energy to get it working, but I'm always interested to know what else is going on out there.

For the time being I'm also ok with my Staticman instance so there's no rush from my side, but it sounds like an interesting project so why not? And to be clear, I really don't want to steer people away from Staticman, I think it's a cool project, it just saddens me to see it's not that active anymore.

[shaftoe]

For @travisdowns attention and whomever else here that might be interested in a very stripped down version of a "staticman" (only GitHub support, only to create a pull request, and available as a GitHub application), please have a look at this:

https://github.com/shaftoe/static-comments

and let me know what you think and even better contribute if you can 😉

It's definitely alpha but already doing the job to me, it's powering comments for my blog (an example PR here).

For the records, there's no serverless support out of the box yet but I'm waiting for v11 of Probot which has announced a better support for it so for now I'm hosting it the usual good ol' way (on a Debian based self managed VPS).

Maybe Probot can also give some inspiration on how to make Staticman a GitHub app? No idea what's the effort required honestly.

HTH

[lionxlife]

oh amazing. Whenever my next project comes along, will need to try this!

[akhyarrh]

Does this issue related to my request become not found when opening https://address/v3/entry/github/myname/repo ?