How it started

So the other day, I was getting started with TypeScript. It occurred to me that, hey, I might as well build something that actually functions instead of tiny little exercises.

Why a blog though? It’s simple. I don’t need to worry about inventory management or payment integrations. A blog shies away from all those complexities while still leaving room to try out various types of frontend content. It’s basically an interesting sandbox.

What to use for frontend?

Since I’m learning TypeScript, not using it is out of the question. What comes next?

Angular feels quite familiar. It’s a full-fledged opinionated framework. It uses DI (Dependency Injection) and has decorators, much like annotations in other frameworks. Routing, HTTP services, state management, etc.- all provided within. Intriguing, but an enterprise-level beast is too much of an overkill for my current use case.

I know a thing or two about Vue, but I can’t say I’m comfortable with it. It’s flexible, minimalistic, and progressive—qualities I appreciate. However, what I can’t quite get used to is its lack of structure. Simplicity has its charms, but I personally prefer JSX over template-based syntax.

And thus, I’m down for React. It seems like a middle ground. It’s an unopinionated library comes with flexibility and a great variety of tools. While Vue labels itself as a “progressive framework,” from my point of view, React is the more “progressive” or flexible option.

Vue can be introduced in small pieces into a project without overhauling it. It gives you a complete package the works well for most use cases, such as handling props with built-in validation and two-way binding. As you scale your app, you’re often nudged to adopt Vue’s full ecosystem.

React, on the other hand, adheres to the principle of single responsibility: it has only one job—rendering UIs—and it doesn’t care about the rest. It’s up to you to decide how you want to integrate it. And that’s why it comes with a steeper learning curve: you’ll have to make your own decisions. State management, routing, side effects… how to handle them? You’re the boss.

In short, this is my take:

• Angular: Batteries Included

Comprehensive and sometimes overwhelming. You get everything you need without much external dependencies. It takes quite some preparations. Just like a feast.

• Vue: Ready-to-go

Simple and efficient. You get what you need to get started with a basic structure and minimal setup. It’s a quick set meal.

• React: A La Carte

Lightweight and flexible. But unlike Vue, You get the basics, and you can take your sweet time to build out your stack to your taste. It offers the flexibility to build something tailored without too much effort upfront.

What about the backend?

Although I love Spring Boot and Hibernate combo, it’s yet another overkill. So I took a next step forward from React—Next.js.

In a nutshell, Next.js is a fullstack framework that combines React for the frontend and Node.js for backend logic, enabling both to coexist in a single codebase.

As for content management, I suppose a headless CMS will do more than suffice. I hesitated between Obsidian and Notion, ultimately choosing Notion because its table features align well with my needs.

npx create-next-app

I was tempted to fork a repository. Tweak it for a bit to see how things work. I actually forked the Blog Starter Kit on Vercel, which served as my reference. I built this from scratch instead of tailoring the starter kit.

Yes, I know, don’t write your own code, don’t reinvent the wheels. But it surely does no harm walking things through step by step.

My pick

Next.js (Frontend and Middleware)

• Frontend Framework: Next.js serves as the frontend, just as React would, but with added capabilities like server-side rendering (SSR), static site generation (SSG), and API routes. It takes care of the client-side user interface and interacts with data fetched from Notion.

• Routing: Next.js provides file-based routing, automatically handled through the folder structure within the /pages directory.

• API Middleware: In the absence of a full backend like my beloved Spring Boot, Next.js also acts as middleware by offering API routes. These routes can handle logic such as fetching data from Notion’s API, processing it, and sending the appropriate response to the frontend. Pretty much like a lightweight backend within the frontend framework.

• Rendering Strategies: Next.js handles different rendering strategies (client-side, SSR, SSG) depending on the needs.

Notion (Headless CMS and Database)

• Content Management: Notion acts as the headless CMS, providing a database to store these blog posts. (aka my notes)

• Data Storage: Notion’s tables (databases) hold the content and metadata (e.g., post titles, tags, dates). Next.js queries these tables using Notion public API, retrieving and rendering content for the frontend.

• No-code Backend: Notion abstracts these steps, offering a no-code solution where I define data fields and properties directly within its interface. The backend logic (CRUD operations, fetching posts) is handled through the Next.js API routes connecting to Notion.

That’s about the gist of the first step.

Reference

1. Next Blog Starter Kit: https://vercel.com/templates/next.js/blog-starter-kit

1. Notion API: https://developers.notion.com/reference/intro