3 ms·

Wouldn't it be simpler to host a lightweight dynamic website? Automatic commits to a git repo of a static website to make it reflect dynamic data reminds me of

Wouldn't it be simpler to host a lightweight dynamic website? Automatic commits to a git repo of a static website to make it reflect dynamic data reminds me of https://news.ycombinator.com/item?id=15272144 https://news.ycombinator.com/item?id=15272144

webrender 9y ago
There's a couple different reasons I ended up going with this solution for my site: 1) Most of the time, integrating social networks into your site means either a) using widgets that are hard to work into the main site flow or b) having a backend to pull and integrate social media posts for you. This solution essentially provides B without needing to maintain a backend. 2) When planning my site refactor, Github Pages appealed to me because of its speed and simplicity. This lets me preserve the site automation that would previously have required a CMS, and because the site is static and hosted by Github, I don't need to worry about bandwidth or usage limits.
saulrh 9y ago
I'm doing the same thing for a few of my personal tools, and once you get over the instinctive revulsion it's a remarkably nice data flow. For example, I maintain state for an IRC D&D game using a bot that publishes to a github static page after every character-sheet edit. The big win is that I don't have to worry about hosting or availability - the bot only has to be up when the game is in session, the rest of the time, github provides for anyone that wants to look at their character sheet or anything. I do the same thing to maintain an el cheapo bash.org slash bucket [1] for a discord community I'm part of; again, a discord bot is significantly easier to keep alive than a website. [1] https://github.com/zigdon/xkcd-Bucket https://github.com/zigdon/xkcd-Bucket
icebraining 9y ago
You'd still need a cache, because you shouldn't be hitting the Twitter API every time you load a page. Then you might have to add a frontend cache to avoid having to regenerate the HTML every time. This solution allows you to avoid those two caches while being more efficient, since everything is only generated once.

webrender 9y ago

There's a couple different reasons I ended up going with this solution for my site: 1) Most of the time, integrating social networks into your site means either a) using widgets that are hard to work into the main site flow or b) having a backend to pull and integrate social media posts for you. This solution essentially provides B without needing to maintain a backend. 2) When planning my site refactor, Github Pages appealed to me because of its speed and simplicity. This lets me preserve the site automation that would previously have required a CMS, and because the site is static and hosted by Github, I don't need to worry about bandwidth or usage limits.

saulrh 9y ago

I'm doing the same thing for a few of my personal tools, and once you get over the instinctive revulsion it's a remarkably nice data flow. For example, I maintain state for an IRC D&D game using a bot that publishes to a github static page after every character-sheet edit. The big win is that I don't have to worry about hosting or availability - the bot only has to be up when the game is in session, the rest of the time, github provides for anyone that wants to look at their character sheet or anything. I do the same thing to maintain an el cheapo bash.org slash bucket [1] for a discord community I'm part of; again, a discord bot is significantly easier to keep alive than a website. [1] https://github.com/zigdon/xkcd-Bucket https://github.com/zigdon/xkcd-Bucket

icebraining 9y ago

You'd still need a cache, because you shouldn't be hitting the Twitter API every time you load a page. Then you might have to add a frontend cache to avoid having to regenerate the HTML every time. This solution allows you to avoid those two caches while being more efficient, since everything is only generated once.