Moving to a GitHub CMS

[swyxio]

---

published: true description: Discussing the 2022 migration of swyx.io to SvelteKit and GitHub Issues category: note slug: github-cms tags: Meta, Blogging canonical_url: https://swyxkit.netlify.app/moving-to-a-github-cms cover_image: https://user-images.githubusercontent.com/6764957/151311175-9a15d313-cace-48a0-844e-2361644a21f5.png

Here are my requirements for blogging platforms:

• Should be easy and fast to update - no long or flaky build process
• Should store images easily - as simple as a paste from my clipboard - anything else is unnecessary friction
• Should be easily editable from mobile
• (optional) should support comment system and different layout formats
• (optional) wysiwyg markdown based editing - no funky blocks with lots of lockin

After thinking through local markdown, GraphCMS, Notion, Strapi, Directus, and so on, I've finally settled on using GitHub as a CMS.

I've long admired the OneGraph approach to blogging:

• https://github.com/OneGraph/onegraph-blog
• https://github.com/OneGraph/onegraph-changelog/issues?q=is%3Aissue+sort%3Aupdated-desc+is%3Aclosed+label%3APublish

However their use of Relay is a bit too high overhead for me. So I built my own using just the GitHub REST API.

The primary problem with GH's API is that it rate limits at 5000 requests an hour, which is dicey for a high traffic blog. So either you prerender at build, or you cache on request (we can also cache on build). Netlify's On Demand Builders are a partial solution to this - partial because content updates will not be respected. I think this is an acceptable tradeoff for all the other functionality github as a cms offers.

The PR for doing this is available here: https://github.com/sw-yx/swyxkit/pull/9

Edit: users may also want to explore using Utterances for authed comments https://github.com/utterance/utterances

[beckelmw]

I've done something very similar. I initially hit the github API from a cloudflare worker and respected their 304 responses to avoid the 5000 daily request limit as much as possible. In the end I found it was cleaner to use a github action to render my markdown to html and push it to workers KV as html. I then use a cloudflare worker to take the html KV content and combine it with my other assets to send a response.

[swyxio]

but why not hit the API and then cache for a day, this will last you until 5000 pages?

[sheldonhull]

@sw-yx you get more traffic than me. I am looking to move away from the current hugo based build setup I have to use github issues to author instead. I have years of images (nothing crazy, just lots of stuff from 2013 on).

I was a little concerned initially with this as all my named images in my pages will no longer be correct, but I guess at the end of the day I just have to rely on the github issues to have that seamless experience with images as well. I'll need to build a migrate script but then it's smooth sailing from thereafter I guess (and easier for devs to engage like on this issue).

Might just build my own go http server as a learning experience despite "reinventing the wheel" to work through issues I take for granted with great tools like Hugo.

Filter Bar

I might just jump start depending on my available time based on your great starter template. Is it relatively simple to incorporate the filtering box you have for categories once I get up and running, as that's the main draw for me, and can be a lot of work to get right.

Discussions vs Issues

Do you see any reason not to use GitHub discussions instead, as I'm already using that for comments. I haven't looked for api parity, but thought maybe of using discussions instead of issues. If you have any thoughts I'd welcome it. I'm considering using this as a chance to work with Svelete/React + Tailwind + Daisy and for the first time making the site completely my own, even if it's simplistic at first.

Reasons I can think of:

• GitHub issues have vscode plugin to let you work directly in a nice editor, also Gitkraken Boards and more work with issues.
• Github discussions can support more complex discussions, but also can be a bit more confusing for focused on-topic discussions with the threading (as much as I love it, many people get this wrong).
• Github actions has lots of automation that might be useful for issues, but probably not as fleshed out for discussions.

[swyxio]

@sheldonhull i think i briefly considered discussions vs issues, but cant remember exactly why I went with issues instead. i think a tiebreaker was the nested nature of comments was a little more complex than i felt i really wanted. i also suspected that i wanted to create a bot to auto-comment each post with a link to the live deployed blogpost, but unfortunately i havent had time to work on the bot yet

i do like that discussions have voting, and stronger categorization. maybe give it a try, i dont think its a bad idea at all

[swyxio]

implemented here! https://github.com/abdulrcs/abdulrahman.id/issues/18