I love github pages. Free hosting is awesome; and so is push-to-deploy. With client-side js apps in vogue; the fact that gh-pages can't run server-side code almost isn't limiting.
If you navigate to a gh-pages URL that doesn't correspond to an actual file in the repository, you get a 404. This makes sense, but makes permanent urls for content in database-driven apps tricky.
This is the standard webapp permalink solution, I guess. Anything after a ?
or #
in a URL doesn't affect the server's routing, and is accessible from JavaScript.
- It works. It's documented. It's been supported by every browser forever.
- lame urls. It might be good enough for a tweet, but not for a user page.
If you want a /table/row
URL, your repository needs to contain a file at /table/row/index.html
. It's super trivial to make a Jekyll plugin to generate content based on a database.
-
good urls
-
you don't have to load the whole app to render one page
-
github's Jekyll builder doesn't support plugins so you have to
jekyll build
to a gh-pages branch manually. Not hard with commit hooks. -
urls only reflect new db changes once you build; ie it only works if you're the only person creating rows.
I haven't seen this in the wild, but it should be possible to set up a server to build your site and push it to gh-pages when it gets pinged by your js app.
-
good urls
-
You don't need to build yourself; users can add rows and get URLs
-
the same server can be also do normal build server stuff like running tests.
-
You need a server. This can potentially negate the freeness of gh-pages, but for many applications a heroku free plan will probably suffice.
-
It doesn't work instantly. This can be fine for one-time actions like creating a user account, but isn't really workable for lots of content
-
It isn't trivial. Another server means more complexity means more opportunities for things to break. You need to be super on-point with integration testing.