Introduction
Have you ever come across developer blogs recounting their project experiences, their challenges, and the knowledge they've gained along the way? These blogs often serve as a testament to their growth and progression, and I've always found them fascinating. Inspired, I decided to launch a blog of my own. However, I wanted to go a step beyond a traditional blog and employ a cutting-edge tech stack. Here's the initial list of requirements that I had for my project:
- A front-end interface to present the blog posts.
- A user-friendly CMS for creating and managing content.
- A reliable database to store CMS content.
Choosing the Right Stack
My initial process involved researching suitable technologies for my stack, jotting notes in Notion as I went along. Suddenly, it struck me – wouldn't it be fantastic if I could use Notion itself as the CMS? Some quick digging led me to discover that Notion offered its own API. I decided to employ Notion as the CMS and NextJS for the front end. After setting up the integration on my Notion account, I familiarized myself with the API's request structure and data format.
During the initial testing phase, I faced a significant issue: slow response times from the Notion API. Although switching to another CMS might have been an easier solution, I was determined to stick with Notion and find a workaround. After some research, I decided to implement caching as a solution for these slow response times.
While brainstorming solutions to address slow response times, I stumbled upon a post about using CloudFlare Workers as a caching layer. This intrigued me, and I decided to give it a shot. CloudFlare Workers run JavaScript or Typescript on CloudFlare's edge network, providing high performance and low latency. These features made them the perfect solution for my caching needs.
Leveraging CloudFlare Workers for Caching
Having decided to use caching to combat the slow response time from Notion API, the next step was implementing it with CloudFlare workers. This was a new territory for me, so I dove into the documentation to understand the setup and deployment process.
My CloudFlare worker had to fulfill two primary tasks:
- Get an overview of all Notion notes inside a Notion database page, along with the pertinent metadata.
- Retrieve the actual content of a specific Notion note.
To hasten the process, I utilized Notion's official SDK. During the setup, I faced a challenge with the dynamic nature of property types in Notion's SDK. To address this, I crafted a dedicated method that would validate the page and confirm all the properties' validity.
With data retrieval from Notion functioning correctly, I turned my focus to caching these results. CloudFlare workers offer a service called KV, which stands for key-value storage, perfectly suited for this purpose. By creating a namespace for a KV and storing the results, I could retrieve and store them with ease.
Next, I automated the caching process. I set a schedule for my worker to run every 10 minutes. During each run, it would update the cache based on any changes in the Notion data. This solution effectively mitigated the slow response times, ensuring my blog was always up-to-date with the latest changes on Notion.
Creating GraphQL Endpoints with CloudFlare Workers
With the caching implemented, I needed to set up response endpoints for the worker. As CloudFlare workers don't have a built-in router, I decided on creating a GraphQL endpoint. I found YogaJS to be an excellent package to integrate a GraphQL server on a serverless (Which is ironic I know) CloudFlare worker. I was able to set up a schema for the page object and two query resolvers—one for all pages and another for a single page based on its slug.
Bringing the Blog to Life with NextJS
With the backend set, it was time to bring the blog's design to life. I started by drafting the blog's layout on Figma. Then, I used NextJS to transform this design into functional components. I created two fetch requests to communicate with the GraphQL endpoint. The data returned as expected, bringing us one step closer to the final product.
Deployment with CloudFlare Pages
The final step was deploying the blog. Since I was already using Cloudflare workers, deploying with CloudFlare Pages was a logical choice. By integrating Cloudflare with my repository, setting up continuous deployment, and configuring environment variables, I managed to launch my blog site. It's now live and accessible globally.
Wrapping Up
Although the blog may look simple from the outside, it incorporates a complex technical stack. I've learned a tremendous amount from this project, and I've enjoyed overcoming the various challenges along the way. I'm eager to continue sharing my journey and learning experiences on this blog.