The Process of Building SecondBrain🧠

1. Requirements

• Low operating costs

  Since I'm still a student, it was burdensome to have continuous operating costs on sites that would run in the long run. Low or no operating costs was considered as the top requirement.

• High flexibility and customization

  Since it will be operated as a technology blog, a table of contents(toc) and category feature that can organize and show complex contents at a glance was essential. However, there were no that kind of feature I like among the free blog services, such as WordPress, Blogger, and Tumblr. Therefore, I decided to use open source software or Framework instead of blogging service for customization.

• Neat Style

  I sought a neat, sleek style that suitable for my tech blog. The objective of tech blog is just conveying information without any unnecessary features. I didn't want to create a heavy homepage with design elements that are unnecessary for technical blogs.

• Theme

  On a new framework, it takes a long time to create a page from scratch while learning the unfamiliar grammar it provides. Above all, in terms of studying, I didn’t think I could learn much through applying grammar specialized in the framework, considering it costs lot of time and effort. In addition, using theme that other cool developers had already developed, I can pay attention to writing which is the original purpose of technology blogs, besides other factors.

• Security

  Of course, I was willing to use theme created by others to some extent, but if it relies on too many packages, I excluded it. Looking at the NPM Hacking issue, I thought I should avoid installing many third party packages that I don't know well on my local computer. In the case of theme which uses too many packages, I can't review all the stability of the packages, so I excluded them for security.

2. Choosing a Tech Stack

Before I chose tech stacks, I realized that the deep understanding of rendering techniques should be needed. Therefore, before I go any further, I first understood what CSR, SSR, SSG actually is.

Read my post : CSR, SSR, SSG

Also, while I researched this, I had another question. When it comes to React.js framework, there are two popular options: Gatsby or Next.js. Which one is the best option?

Read my post : Gatsby VS Next.js

👩‍💻 Doing this, I intended to carefully evaluate the technology and select a technology stack that fits the project objectives.

---

2-1. Operating expenses

	Characteristic	Operating expenses
WordPress.org	(self-hosted) CMS software	Need to pay the cost of hosting server(Apache, Nginix) and a domain name. ⇒ Expensive
Ghost CMS	(self-hosted) CMS software	Need to pay the cost of hosting server and a domain name. ⇒ Expensive
Gatsby	static site generator	Need to pay only the cost of a domain name. (If you use free Netlify or Vercel hosting plan, it provide its free domain.) ⇒ $0
Next.js	static site generator & SSR	Need to pay only the cost of a domain name. (If you use free Netlify or Vercel hosting plan, it provide its free domain.) ⇒ $0
Docusaurus	static site generator	Need to pay only the cost of a domain name. (If you use free Netlify or Vercel hosting plan, it provide its free domain.) ⇒ $0

2-2. My experience of …

(1) WordPress

• PHP

  I'm not saying that php is a bad language, but each person has a preferred language, and vice versa. It was no longer my preferred language.

• Heavy CMS

  WordPress is a CMS designed to build a web for many purposes. You can build a blog, or you can build a company's landing page even a shopping mall if you want. That's why WordPress is powerful. However, rather, such a characteristic came to me as a disadvantage. The speed wasn't fast, and the dashboard had a lot of unused settings lined up in disorder.

• No Markdown editor

  The WYSIWYG editor that WordPress supports was easy to format, and HTML was well recognized. However, it wasn't compatible when migrating to other places, and I didn't really like it as I prefer to write with a markdown whatever I personally wrote.

• Hosting costs

  Since it is based on php, web servers such as Apache and Nginix had to be attached, and server costs were inevitably incurred. The world has come where you can host blogs for free using static website generators such as Jekyll, Hexo, and Gatsby running on Github Pages or Netlify.

• Style

  There are many high-quality style, but it was difficult to find a neat style that is perfect for technical blogs.

(2) Ghost

• A weak Node.js support policy

  I found that the latest version of Node.js that I’m using right now in my local computer is not supported by Ghost team. Since Ghost team is small yet, there was lack of supported version of Node.js. On the other hands, Gatsby has much larger market size than Ghost yet, so it supports almost every version of Node that has a release status of Current, Active, or Maintenance.

• Hosting costs

  I have to pay for hosting server anyway, like WordPress.org. Even though they have Ghost Pro service for hosting, it’s paid service.

(3) Next.js

• Lack of templates & plugins

  It is very similar with Gatsby, but also has some difference. I have written a detailed blog covering the difference between Gatsby and Next.js and you can read here. Since Next.js is very unopinionated, it neither offers any templates in particular nor supports plugins. However, Gatsby has amassed a huge collection of templates and plugins that work seamlessly with the framework to support rich use cases, which otherwise wouldn’t be possible with vanilla Gatsby. Therefore, I preferred Gatsby to Next.js because of templates and plugins.

(4) Gatsby

It has a rich ecosystem of plugins and themes. I looked quite great choice to save time and simplify the development process building Gatsby blog with a theme from GitHub. So, there was no reason to hesitate. I started my project right away. However, the more I experienced this Gatsby theme, the more problems I discovered which are :

• Security risks

  If you download a theme from an untrusted source, there is a risk that the theme could contain malicious code that could compromise the security of your site or computer. To avoid this risk, it's important to carefully vet any themes that you download from GitHub or other sources and make sure that you trust the source. In reality, however, it was impossible to review and use many of the packages when I select the theme.

• Compatibility issues

  Themes may not always be fully compatible with the latest version of Gatsby or with other plugins or packages that you may be using. It's important to thoroughly test any theme that you use to ensure that it works well with your site and does not introduce any compatibility issues.

• Maintenance challenges

  If a theme that you are using is no longer actively maintained by its creator, you may run into issues with bugs, compatibility, or security vulnerabilities. It's important to keep an eye on the status of any themes that you use and be prepared to switch to an alternative theme if necessary.

Therefore, I began to looking for other frameworks that could replace Gatsby’s theme features.

(5) Docusaurus

I was looking for a framework that has already beautiful default blog page, which mean there is no need to use any theme from other developers so I can use official, and trustful code only. That’s where Docusaurus comes in! 🤩🤩

Docusaurus is a framework for building documentation websites, but it also comes with a default blog page that is already designed and styled, making it a great choice for quickly setting up a blog without the need for additional themes or customization.

The default blog page in Docusaurus includes features such as post categories, tags, and search functionality, and can be easily customized with your own content and branding. Additionally, Docusaurus provides a number of built-in plugins and features, such as support for Markdown, syntax highlighting, and automatic deployment.

3. Tech Stack that I Used

1. Language
   1. TypeScript
2. Library
   1. React
3. Framework
   1. Docusaurus
4. Infra
   1. Vercel
   2. Github Actions
5. Tools
   1. Algolia
   2. Google Search Console
   3. Google Analytics

4. Roles in the project

1. UI/UX Design
2. Layout and function customization through Docusaurus Swizzling
3. SEO Optimization
4. Integrate and connect Analysis Tools for product operation

5. Improvement

5-1. Problem that I faced

• Local Storage Problem

  This problem is an essential problem for SSG. Using a SSG usually involves storing Markdown files locally in the code repository. Due to this, the main disadvantages of SSG is that having too many pages generated at the build time can increase the project size and also the build time. Every time I need to write an article on my device, I upload it manually via the terminal, and it takes from minutes to minutes until the post gets updated and appears regardless of the (errors) that I sometimes encounter and need some time to solve it. What’s more, I need my computer every time you have to adjust, which means that if I’m traveling, it’s hard to make adjustments.

5-2. How I solved

I wondered how ChatGPT answer to this question, so I asked it. My question was : Suppose that my local folder for Github repo is getting so bigger that there is lack of storage in my local computer. Is there only way that change the storage of my local computer?

If your local folder for the GitHub repository is growing too large and you're running out of storage on your local computer, there are a few alternative options you can consider:

1. Clean up your local repository: You can go through your local repository and remove any unnecessary files or folders that are taking up space. This can include temporary files, generated build artifacts, or any other files that are not required for the functioning of your site. By keeping only the essential files, you can free up storage on your local computer.
2. Use Git sparse checkout: Git sparse checkout allows you to clone only a subset of files from a repository instead of the entire repository. Sparse checkout is commonly used when you want to limit the files and directories checked out into your local working copy.
3. Utilize Git's partial clone feature: Git's partial clone feature allows you to clone only a portion of the repository based on file paths and filters.The partial clone is preferred when you need to clone and work with a specific subset of files and history, particularly for large repositories. When you make changes to the files in your local working copy, you can still use Git commands like git add, git commit, and git push to upload your changes to the original GitHub repository.
4. Use a cloud-based development environment: Instead of relying solely on your local computer for development, you can consider using a cloud-based development environment. Platforms like GitHub Codespaces, Gitpod, or cloud IDEs provide an online development environment where you can write code and work with repositories without the need for significant local storage. These services typically offer storage and computing resources in the cloud, alleviating the storage constraints on your local machine.

By employing these strategies, you can manage your local storage more efficiently while still being able to work on your static site using SSG rendering.

ChatGPT gave me great solutions that enable us to manage local storage while pushing every changes to GitHub repo.

---

Or, Use Headless CMS, not pushing every changes to GitHub repo.

Furthermore, if it’s possible to change the structure (even though it takes lot of time), there is also another way to solve local storage problem. Instead of pushing every changes to GitHub repo, you can change the architecture into retrieving content from headless CMS using its API, and integrating it into your frontend application.

Then you don’t have to store Markdown files locally in the code repository. Then, you don’t have to use a code editor to write content (because the headless CMS has the administrative interface called Content Management Backend.) and use a GIT workflow to publish (because the headless CMS exposes a content delivery API.)

Instead of storing Markdown files locally, you can use a headless CMS to manage your content. It will allows you to create, edit, and organize your content through a web-based interface. But, this is seen as over-engineering.

💡 I was worried about how I would handle the file size later, but I decided that it was over-engineering to worry about it even before I started. When the file size increases later, I will solve that problem considering the situation at that moment.

6. Conclusion

Experience is the key to understanding. When I just looked at the documents before I code, everything was vague and It was difficult to determine which was the better option. However, as soon as I started, I could draw a big picture of it and new requirements came in my mind to build better blog.

I’m sure that if you just go deep into code, you could have better understanding of the logic and get your own preference with well-founded reasons. To sum up, my lesson here is : Just code, learn how it works, and compare it with others!