I completely rewrote my personal website using Dev.to as a CMS

The final weekend of January 2021 was uneventful in comparison with other years - in the UK we were in full lockdown due to the Coronavirus. It was, however, the perfect opportunity to completely rewrite my personal website.

Why?

I decided to redesign and rewrite my website for several reasons:

• I wanted to move from JavaScript to TypeScript.
• The website was styled using styled-jsx, which can be a pain to maintain and IMO is a bit messy. At the moment I'm using Tailwind CSS and so far loving it and its utility-style nature; I wanted my personal website to reflect this.
• I no longer liked the design and wanted it to be cleaner and simpler.
• I wanted my blog and portfolio to be loaded dynamically from a CMS rather than having to copy+paste a new page for each entry - See the Originally published at wallis.dev at the top of this article.

My old home page

Technologies used

• TypeScript - Since being introduced to TypeScript at work, I've started to understand the benefits over plain JavaScript.
• Next.js - I don't try to hide the fact that I love Next.js, it's so simple to use and to date most of my articles contain Next.js in some way.
• Tailwind CSS - Lately I've been using Tailwind CSS heavily. To quote their homepage, it enables me to "rapidly build modern websites without ever leaving [my React component]". Tailwind CSS also made it incredibly easy to add a dark mode.
• Dev.to API to dynamically build the blog and portfolio pages ⬅️ My favourite feature.

Using Dev.to as a CMS

My favourite part of my website is the use of Dev.to as a Content Management System for the blog and portfolio pages. I've seen the Dev.to API utilised before to display a user's articles on their website but, AFAIK, not quite in the same way as I've applied it.

The benefits of using Dev.to as a CMS are:

1. Dev.to stores the articles and any images that are uploaded and used.
2. I can use Dev.to's editor and the ability to draft an article and publish it later.
3. Has a built-in RSS feed that I can use to share my articles to other sites such as CodeNewbie and Medium.
4. Converts the article into HTML meaning I don't have to convert the article Markdown myself.
5. Although Dev.to has the article first, the use of a canonical URL ensures that Google and other sites see my personal website as the source site for the articles.

Disclaimer

Before I continue I want to stress that I intend to use Dev.to purely for my blog and portfolio (past projects / showdev). I won't be using Dev.to to create pages which are not articles and would cause Dev.to to become cluttered with spam if others follow suit. For example, the about section on the home page is hardcoded into the website and if I created a page for my education history, I'd keep that purely for the website and wouldn't post it to Dev.to - I'd probably use Markdown for these.

How it works

View the code on GitHub

Built using Next.js, the website uses two dynamic routing functions (getStaticPaths and getStaticProps) to generate the blog and portfolio pages.

Before an article is displayed on my website, it must meet the two following requirements:

1. Must be published (obviously)
2. Must have a canonical URL directing to my website. This enables me to pick which articles are displayed, what the article's path will be on my website (not the post ID). Moreover, an article with a canonical URL pointing to https://wallis.dev/blog/... will be built as part of my blog whereas, if its canonical URL is https://wallis.dev/portfolio/... it will be a portfolio piece.

For every article that meets the requirements, the subsequent build process is followed:

• At build time, Next.js calls the getStaticPaths function which fetches a list of my published articles using the Dev.to API. A dynamic page is created within the Next.js context for each article - the page slug will be the canonical URL path.
• For each page, Next.js calls getStaticProps which produces a further request to fetch the details of the page's article via the Dev.to API. The Dev.to response contains the article name, description and rendered HTML as well as other information.
• Finally, the page is rendered. I use custom elements to display the article name and description and then display the rendered HTML that Dev.to supplies using dangerouslySetInnerHTML.

To ensure that the website is always in sync with my articles on Dev.to I use a Vercel Deploy hook which is triggered each time I create or update an article using a Dev.to webhook.

Note: I use Dev.to APIs that require an authorisation. When using public APIs I found that my builds were failing with a 429 error which, I believe, is Dev.to rate-limiting requests. Although undocumented, I seem to get a higher limit when authenticated - although my builds do sometimes fail when rapidly updating multiple times.

I'm currently writing a detailed article which describes in greater detail how my website utilises Dev.to as a CMS, stay tuned (and follow on Dev.to to be notified when I release it)!

How it looks

Visit wallis.dev

Navigating through wallis.dev

Future improvements

1. Add syntax highlighting to code blocks like on Dev.to.
2. Add a contact form using EmailJS.
3. Only rebuild the website if the content of an article has changed or one is created. This would solve the build failing when articles are rapidly saved.

Summary

In this article, I discussed rewriting my personal website from the ground up using Dev.to as a Content Management System for the blog and portfolio pages.

Like the idea of using Dev.to as a CMS for your blog? React! Found something I could improve or that you would have done differently? Let me know in the comments.

Thanks for reading!