Staticman public instance not available

[alexwaibel]

Trying to add the user @staticmanapp as a contributor returns no results and the user page for staticmanapp is not available.

The public instance of the api is still running but has not been verified to be functional. https://api.staticman.net

Will consider deprecating support for public instances and instead instruct users on how to host their own for free elsewhere such as Heroku.

Edit: The GitHub app appears to be up.. This one seems to be what those using the publicly hosted version are having success with.

[alexwaibel]

@eduardoboucas I have a lot of questions about the deployment process for all of the public interfaces to this app

• what is hosting the public API?
• Is the staticman github app found here running that same instance?
• Is the public website also hosted there?
• Are these running some kind of continuous deployment?

[sukiletxe]

Public instance works for me (ev subdomain,v3). See <https://github.com/sukiletxe/sukiletxe.eu/pulls> .

…

El 8 nov 2019, a las 4:14, Alex Waibel ***@***.***> escribió:  @eduardoboucas I have a lot of questions about the deployment process for all of the public interfaces to this app what is hosting the public API? Is the staticman github app found here running that same instance? Is the public website also hosted there? Are these running some kind of continuous deployment? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[alexwaibel]

@sukiletxe Interesting. From your repo it appears you're using the dev.staticman.net domain. From what I've read in this issue you should switch to the api.staticman.net domain if possible. Thank you for the reply though, as many reports of working instances as I can find will help me best understand the current state of this app since builds seem to have been broken for a while based on Travis.

[sukiletxe]

I can answer the public website question, it’s the staticman.net repo served using github pages and redirected using cname (or it seems so at least)

…

El 8 nov 2019, a las 4:14, Alex Waibel ***@***.***> escribió:  @eduardoboucas I have a lot of questions about the deployment process for all of the public interfaces to this app what is hosting the public API? Is the staticman github app found here running that same instance? Is the public website also hosted there? Are these running some kind of continuous deployment? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[eduardoboucas]

what is hosting the public API?

Heroku. It's currently on a free tier, so it very quickly reaches capacity.

Is the staticman github app found here running that same instance?

Yes.

Is the public website also hosted there?

As @sukiletxe rightly pointed out, the codebase of the website is on this repo and it's running from GitHub Pages.

Are these running some kind of continuous deployment?

Yes. Anything that is merged to master on this repo will be deployed to api.staticman.net. Anything merged to dev will be deployed to dev.staticman.net. Anything merged to master on the website repo will be deployed to staticman.net.

[alexwaibel]

Thanks Eduardo. Being a free heroku instance explains our reliability issues. Probably just can't handle the traffic. For now it may be best to leave it up but stop suggesting people use it in documentation until I get time to host an instance on something more robust.

[bashlk]

Hi guys,
As @eduardoboucas suggested last year (#243 (comment)) I wrote a simple wrapper around staticman so that it can be used as a netlify function (https://github.com/Bash2/staticman-netlify-function). Hopefully, this will be a better alternative than the failing public instance.

[alexwaibel]

I'm not super familiar with either, but I'm not seeing any real benefit to suggesting netlify over heroku. Is there any? Heroku seems much simpler for the general user since it can deploy from GitHub forks.

[sukiletxe]

I haven't used either of them, but I'm more familiar with Netlify (since I host my site there). Basically with Netlify you put a file in a special folder and it becomes a site endpoint (you put comments.js and it becomes /.netlify/comments). So you don't have to register anywhere else, and Staticman would live next to your site. Hopefully @Bash2 can give a better explanation.

[bashlk]

The biggest appeal for me to use netlify is having everything in once place instead of scattering it across multiple providers/hosts and having to setup/configure each. (Assuming that you already host your site on netlify that is) It also feels excessive to me to start an entire instance when a lot of the functionality (the http serving/routing with express for example) is provided by netlify functions out of the box but that just might be me.

It essentially works as @sukiletxe describes, where js files placed in the functions folder are deployed as an endpoint alongside your site.

Within the free tier, netlify allows 125K function calls which should be plenty for most cases and by using your own github token within this, the authorization step is not necessary anymore. Each user would have their own Staticman function for their own needs.

As for installation, a cool idea might be to write a simple app that makes a pull request to your static site repo doing all the file copies/edits and then the function is automatically deployed once merged.

[alexwaibel]

I'm still not convinced that the conversion to a serverless netlify architecture really solves our problems. I think it's a safer direction to stop recommending the public instances in any documentation (while leaving them running anyway because apparently a lot of people still use them) and suggesting people fork and deploy the repo to heroku. The deployment to heroku from GitHub is very straightforward and the free instance should be enough for hosting a private static man instance. I'm open to further discussion though. It seems unnecessary to offer a public instance when there is no barrier to everyone hosting their own simple and free heroku (or otherwise) instance.

[sukiletxe]

Why not @alexwaibel ? To summarice, here are our main problems:

• Lack of updated documentation (solved by updating it, the solution is independent of which path we choose)
• Unclear how v3 works, at least for me. Once it becomes clearer, Heroku would be an advantage, since the netlify function provided above only works with V2. This could be fixed. Primary use of V3 would be to gain support of GitLab (maybe other providers are integrated, though I don't think so)
• Public instance not working due to excessive request and absence of bot. Remove public instance from docs as you said. Then, either solution can work. I have no idea about Heroku's limits (other than the dyno sleeps after 30 minutes of inactivity and that the first request is delayed, no idea if requests ever get lost). Netlify offers a free tier for Lambda functions which has a 10 second per function execution limit and 125k requests per month. No idea if this could work in less than 10s, but if it does, it's as easy as the other alternative. Assuming one knows how package.json works, one could even pin versions to specific commits, marking them as stable (just like self-hosting would work, I believe).

[alexwaibel]

@sukiletxe From what I understand of this application, V3 is meant to add an additional authentication option where Staticman runs as a GitHub application rather than a GitHub bot account. Getting back to the Netlify discussion, Heroku works without adding any additional code to the repo. Supporting Netlify would require additional code which must also be maintained. In contrast, Heroku can deploy the code as-is directly from GitHub. From what you have described, the 125k requests/month on Netlify would provide far less bandwidth than the free tier of Heroku based on this StackOverflow post.

Heroku seems to be the easiest hosting solution to recommend to general users from everything I've read. Of course, you can always run the application on any other hosting platform you wish.

[alexwaibel]

This has been resolved with #319. We are dropping support for the public Staticman instance and are recommending that all users host their own instance. The simplest way to do this is to click the "Deploy to Heroku" button in the README which will allow you to host your own instance for free without the reliability concerns of using a singular public instance. The public instance will remain running for the time being, though I strongly recommend everyone move away from it.

[VincentTam]

@sukiletxe From what I understand of this application, V3 is meant to add an additional authentication option where Staticman runs as a GitHub application rather than a GitHub bot account.

@alexwaibel That's not what it meant when PR 219 was merged into the dev branch two years ago. The version number increment came from the discussion about the GitLab support: in the v2 API scheme, which supports only GitHub, the endpoint starts with /v2/entry. The author of the aforementioned PR preferred changing the API scheme so that the endpoints for GitHub and GitLab looks similar /v3/git..b/entry.

GitHub Apps was added several months after the merge into dev branch.