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.
I decided to redesign and rewrite my website for several reasons:
- 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.devat the top of this article.
- 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.
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:
- Dev.to stores the articles and any images that are uploaded and used.
- I can use Dev.to's editor and the ability to draft an article and publish it later.
- Has a built-in RSS feed that I can use to share my articles to other sites such as CodeNewbie and Medium.
- Converts the article into HTML meaning I don't have to convert the article Markdown myself.
- 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.
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.
Before an article is displayed on my website, it must meet the two following requirements:
- Must be published (obviously)
- 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
getStaticPathsfunction 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
slugwill be the canonical URL path.
- For each page, Next.js calls
getStaticPropswhich 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
descriptionand then display the rendered HTML that Dev.to supplies using
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)!
- Add syntax highlighting to code blocks like on Dev.to.
- Add a contact form using EmailJS.
- 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.
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!