Thought Process Behind Launching This Blog
I'm sharing the items and contents I considered when launching this blog. This covers everything from the purpose to the choice of frontend frameworks and headless CMS.
I've compiled the initial thoughts I had when launching this blog.
【Purpose】
By blogging about the technologies I've acquired, I aim to lead to an accurate and deep understanding of the technology, and as a bonus, attempt to monetize it to supplement server maintenance funds. Therefore, the priorities are as follows:
- Acquire the latest technology.
- Keep operational costs as low as possible. If expenses exceed revenue, continuation becomes difficult.
- Minimize non-article efforts, such as operational hassles and posting articles.
- The content of the articles is planned to be primarily technical, followed by hobbies.
【Considerations on the Operating Environment】
I listed operating methods for starting a blog.
<Disadvantages of Free Sites>
- Does not lead to acquiring the latest technology.
- Free sites automatically display ads, increasing displays that don't lead to revenue. Also, unintended ads may be shown.
- Since it becomes a dedicated blog site, the effort is probably minimal.
<Disadvantages of Paid Sites>
- Does not lead to acquiring the latest technology.
- The problem is that it costs money. High chance of quitting without continuing.
- Probably the least amount of effort.
<Independent: WordPress + Home Server + Cloudflare Tunnel>
- Only Cloudflare Tunnel is novel.
- Basically free, so continuation is easy.
- WordPress itself has become highly functional, tending to complicate management like article updates, incurring some learning costs. *Within an acceptable range?
<Independent: JS Framework + GitHub + Headless CMS + Cloudflare Pages>
- Content management via Headless CMS, a new form of CMS, plus a JS framework.
- Basically free, so the purpose is achieved.
- Operating via SaaS is good, but if the service ends, you're stuck. Increased switching costs and effort.
【Development Environment】
Therefore, based on the above considerations and the framework information below, as part of my studies for future large-scale app development, I decided to try building a blog site with a frontend framework + headless CMS + Cloudflare Pages.
<Regarding the Editor>
For a development code environment, it's common to install an integrated environment called an IDE and add extensions suited to the development environment. VS Code is optimal, but since the lightweight and fast Zed has implemented Astro extensions, I will use that.
<Desktop Environment for Development>
Code development requires integration with other cloud services like npm (Node Package Manager) and GitHub. (Reference: npx stands for "Node Package Execute." Unlike npm, it's a command-line tool to temporarily execute Node.js packages without installing them, running them without polluting the environment.)
OS Type | Features |
Linux | It's said that about 70% of the world's web servers are Linux. It has a high server share and the most development tools. However, the refinement of the desktop GUI and app support are significantly lower than Mac or Windows, making it less suitable as a developer's machine. |
macOS | Originally developed as a Unix-like OS, it is strong with Linux commands, and most Linux commands can be used. The desktop interface is excellent and is chosen by many developers as their development machine. |
Windows | The share for business and general use is overwhelming, and since it's also suitable for gaming, it has the top desktop machine share. By installing WSL (Windows Subsystem for Linux), you can realize a Linux environment on Windows. Basically, it runs Linux as a virtual machine and shares files, taking the best of Linux. Since v2.0, many users have been utilizing it. |
A blog environment doesn't require an advanced development environment, so either Mac or Windows is fine, but to save the trouble of installing WSL, I will proceed with macOS this time.
【Dev Container】
In development by multiple members, unifying the development environment using DevContainers is major. However, honestly, introducing DevContainers in an environment that can be developed by one person, like a blog, seems more troublesome to maintain, so I put it on hold this time.
【Features of Frontend Frameworks】
Usually, a collection of convenient functions and libraries compiled according to a "design philosophy" for building a site is called a framework. Following that design philosophy when writing code makes site development efficient. While it requires understanding the philosophy and learning the code's features, after learning, consistency is born across the implementation code, making it easier to read and tending to have fewer bugs, making it an essential element for large-scale sites.
Framework Name | Creator | Features |
React (Many Users) | Meta (Facebook) | UI is managed component-based, and rendering is fast because only differences are rendered through the Virtual DOM. Closer to a UI library than a framework. *I personally dislike it |
Vercel | A full-stack framework based on React. While React is client-side only, this includes the server-side, allowing for more optimal rendering methods and faster drawing. *Currently deprecated! (The CEO is garbage, so I dislike it now) | |
Vue.js (Many Users) | Evan You | Individuals are simple with low learning costs. Various things are possible through individual combinations. Component-based. Because it's simple, it can be combined with various libraries. Many Japanese resources. I personally like it. |
Alexandre Chopin, etc. | A full-stack framework based on Vue.js. Particularly good at building sites using SPA (Single Page Application). | |
Astro Technology Company | Astro renders the entire page into static HTML and achieves high performance by removing unnecessary JavaScript. Designed to allow concurrent use of various UI frameworks like React or Vue. More suited for MPA than SPA, initial page display is fast. The optimal framework for a blog. |
<Reference>
- Results of migrating from Next.js to Astro
- React has derivatives like React Native, which can be used to create native smartphone apps. When providing services over a wide area, the learning cost relatively decreases.
- However, for cross-platform development for iOS and Android, Google's Flutter has more momentum than React Native. Since the UI is shared, the operation feel doesn't change even if the model differs, making it particularly convenient for business use. Therefore, I don't think there's a reason to force the adoption of React.
【Open Source (Free) Headless CMS】
There aren't many types of open-source headless CMS that use in-house servers. Like microCMS, many companies provide them as SaaS cloud services. However, there are significant advantages to open source, such as wanting to own the data internally or worrying about usage fees when scaling up. However, an in-house server is required.
Name | Features |
Probably the most famous OSS headless CMS. MIT License. Free for both personal and commercial use, but offers a high-function version for a fee. *The core seems to be React-based. | |
Sanity | Strong point is flexible data schema and real-time collaborative editing. Strong in dynamic content management. Cloud type (SaaS). Free tier available. |
Written in JavaScript, runs on Node.js. Distributed under the MIT license. Official image on Docker Hub. A headless CMS specialized for blog-type websites, with a structure close to WordPress. | |
Formerly Netlify CMS. Distributed under MIT License. Few articles. Git-based open-source CMS. Directly links with Git repository. | |
Many adoption cases in major companies. Implemented in JavaScript, runs on Node.JS. Turns existing SQL databases into high-speed APIs. Automatically converts database structure to API. Makes SQL databases into APIs as they are. | |
Python-based. Adopted by NASA and Google. | |
DB seems fixed to MongoDB. JavaScript-based. | |
Used by Unity. Apache 2.0 license. | |
Corporate development. | |
GPL 3.0 license. Saves as json files, etc., without using a DB. |
<Selection of Headless CMS>
Basically, since it's a personal blog that cannot be sustained unless it's free, it narrows down to those available open source under the MIT license like strapi, Ghost, and Directus. Among those, strapi seems useful for future expansion and building e-commerce sites, so I'll go with this one this time.
【Conclusion】
So, I decided to proceed with Astro + Strapi + Alloydb (PostgreSQL) + TailwindCSS + Cloudflare Pages + Macbook Pro + Zed editor as the technological foundation for this blog. The key here is the build flow.
- Start strapi container on Mac, create articles.
- In the blog creation build, copy static pages and images from strapi, and do not use strapi in production (no in-house server needed!).
- Upload (Deploy) the complete set of production data created by the build to Cloudflare Pages. The site is entirely static data with minimal JavaScript. Display is super fast lol.
The crucial point is that production is all static data. It feels like using strapi only when writing articles.