Behind the Scenes: The Story of Headless Hashnode

Sandeep Panda

·

·

673 views

In the early 1990s, most websites were static, and one needed to know HTML to update content. By the late 1990s, the web saw the emergence of the first set of tools or CMS that made content management easier. The 2000s marked the era of open-source CMS solutions like WordPress, Drupal, and Joomla, which changed the CMS landscape forever. In the 2010s, we witnessed the rapid rise of headless CMS solutions that separated content creation and presentation. The 2020s will likely see more specific and purpose-built headless CMS options. Headless Hashnode is one such purpose-built CMS that excels at developer blogging. Other examples of purpose-built CMS in different domains include Shopify Headless Commerce and CommerceLayer.

However, building headless Hashnode wasn't straightforward. In fact, we never thought we would create this. Personally, I had the opinion that our existing hosted solution was so customizable and personalizable that no one would ask for anything more. I say this because we built Hashnode with one guiding philosophy: giving developers control over their own data. We achieve this through the following:

  • Developers can map a custom domain to their blog for free and go from 0 to 1 in under a minute.

  • A user can automatically get a backup of their content on their private GitHub repo for stress-free ownership.

  • Furthermore, they can apply custom CSS to customize the look and feel of their blog to an extent.

But I was so wrong! This works very well for individual developers. However, most of the businesses want the following two things:

  1. Ability to host their blog on a subpath like company.com/blog

  2. Ability to fully customize their blog frontend!

Take a look at the following tweet:

Based on our conversations with numerous businesses and individual users, we discovered that they want to control their presentation layer while still enjoying Hashnode's unparalleled editing and CMS experience. Before Headless Hashnode, the alternative was to use a generic headless solution like Contentful or Sanity. However, a blog is different from, say, an e-commerce site. A documentation website is different from a blog, and a landing page is different from a changelog site. A generic headless CMS no longer suffices because developers have to piece together various elements and create an experience that can take weeks of their time. This is where purpose-built headless CMS comes into play, which is what our users have been requesting. They want to use the Hashnode editor and CMS for one specific purpose (currently blogging, but we are soon expanding) and have unlimited freedom to customize the frontend to match their own brand guidelines.

There were two ways to solve the above problem:

  • To install Hashnode on a subpath, users would need to reconfigure their DNS to point to us and set up an origin. For example, if a user wants to host Hashnode on sandeep.dev/blog, they would point their apex domain sandeep.dev to us. This is because one can add an A record for the apex domain or subdomain, but not for a subpath. When a request comes to us, we check the configured path and serve the blog if the request path matches the configured path. For instance, we would serve the blog for sandeep.dev/blog/* and proxy to the configured origin for all other requests. However, most companies would not be comfortable handing over their DNS for the apex domain to us. Additionally, they cannot fully customize the frontend. As a result, this option is not viable.

  • Another option is to build public APIs and develop the Hashnode frontend purely as a client for these APIs. This approach would allow us to open-source the frontend as a starter-kit, which anyone could take and host on their subpath. Those who prefer not to use the starter-kit can directly integrate the public APIs!

As you might have guessed, the second option made a ton of sense and is what we ultimately chose to do.

One minor detail is that we already had a set of public APIs at that time, which were not built in the best possible way. Their usage was quite limited since we hadn't promoted them much. We always believed that at some point, we would redesign and relaunch these APIs. However, with the entire concept of public APIs and a starter-kit, we realized it was time to revamp the APIs. A quick analysis revealed that our legacy APIs were receiving 8M+ requests monthly, and people were using them to build various integrations like displaying posts on their portfolios, smart home integration, importers, and more.

So, by addressing all the flaws and relaunching a comprehensive set of APIs, we would not only be able to release a headless version, but it would also open up a ton of other opportunities.

On August 16th, we made the decision and began working on Public APIs v2, which would ultimately enable us to launch headless Hashnode.

Fast forward to early December, we released the public APIs and 3 OSS Next.js starter-kit themes that anyone can use and install on a subpath, allowing for complete customization of the frontend. ✨

I am glad we decided to fix our existing flawed legacy APIs and relaunch them as a truly powerful and robust set of new APIs, which paved the way for OSS starter-kits. It's important to note that users can directly integrate with our APIs to build their blog without having to use the starter-kit. For example, some of our customers, like MindsDB, use the starter-kit to host their blog on a subpath. Others, like Outerbase, prefer to integrate directly for greater control.

The entire journey of creating public APIs has been immensely rewarding for us as a company. It not only assists us with headless mode but also simplifies internal development. Every query and mutation we release is first integrated with Hashnode and thoroughly tested before we make it public. As a result, the Hashnode-hosted blog frontend, which is also built as a client for our GraphQL APIs, helps us monitor and improve the experience continuously. Last month (in January 2024), our APIs were called 81M+ (vs 65M in Dec 2023) times, a number that will continue to grow as we scale. Personally, I am incredibly excited about this new chapter.

If you are a Hashnode user who has outgrown our hosted version, I invite you to check out our headless CMS for blogging! I am leaving a few important resources/links for you to check out:

Fun fact: this blog is also proudly powered by headless Hashnode. 🚀

1 comment
Add a comment