Moving - From DigitalOcean to Cloudflare Pages

Moving - From DigitalOcean to Cloudflare Pages

Daily short news for you
  • Since the Lunar New Year holiday has started, I won't be posting anymore. See you all after the holiday! 😁

    » Read more
  • Continuing about jj. I'm wondering if there are any GUI software made for it yet to make it easier to use. There are already so many similar to git that I can't count them all.

    Luckily, the author has compiled them all together in Community-built tools around Jujutsu 🥳

    » Read more
  • Turso announces that they are rewriting SQLite in Rust. This adds another piece of evidence supporting the notion that Rust is "redefining" many things.

    But the deeper reason is more interesting. Why are they doing this? Everyone knows that SQLite is open source, and anyone can create a fork to modify it as they wish. Does the Turso team dislike or distrust C—the language used to build SQLite?

    Let me share a bit of a story. Turso is a provider of database server services based on SQLite; they have made some customizations to a fork of SQLite to serve their purposes, calling it libSQL. They are "generous" in allowing the community to contribute freely.

    Returning to the point that SQLite is open source but not open contribution. There is only a small group of people behind the maintenance of this source code, and they do not accept pull requests from others. This means that any changes or features are created solely by this group. It seems that SQLite is very popular, but the community cannot do what they want, which is to contribute to its development.

    We know that most open source applications usually come with a "tests" directory that contains very strict tests. This makes collaboration in development much easier. If you want to modify or add a new feature, you first need to ensure that the changes pass all the tests. Many reports suggest that SQLite does not publicly share this testing suite. This inadvertently makes it difficult for those who want to modify the source code, as they are uncertain whether their new implementation is compatible with the existing features.

    tursodatabase/limbo is the project rewriting SQLite in Rust mentioned at the beginning of this article. They claim that it is fully compatible with SQLite and completely open source. Limbo is currently in the final stages of development. Let’s wait and see what the results will be in the future. For a detailed article, visit Introducing Limbo: A complete rewrite of SQLite in Rust.

    » Read more

Problem

If you're interested, you may know that I use DigitalOcean to host this blog, with a modest configuration of 1GB RAM and 20GB SSD, which is sufficient for the TechStack that I have chosen. I call it sufficient because it still performs well with the current traffic, but deploying with Docker sometimes creates storage issues for the images it generates. Docker is known as the "hard drive killer" when you have many Images, combined with CI/CD setup, it's a "devastating combo". Just think, a 20GB hard drive, without subtracting the operating system, how can continuous deployment be possible? Occasionally, the server reports that the hard drive is full and I have to go in and delete some files.

By chance, I came across Cloudflare Pages which provides a solution for deploying various types of websites, such as Vue, React, Nuxt.js, Next.js... I was curious to see what it had to offer. I spent a whole week researching it. Finally, I decided to try migrating the two interface pages to see if it could be done.

The Process of Moving

According to Cloudflare, Cloudflare Pages is a JAMstack platform for user interface developers and website deployment. Pages focuses on developers as it offers many solutions such as Git integration to support continuous deployment (CI/CD), as well as the deployment speed and performance of the application through it.

Realizing the potential of Cloudflare, I could move the two Front-end pages: the admin control panel (AdminCP) and the blog interface. The AdminCP is built with Vue.js using SPA, while the blog is built with Nuxt.js using SSR. For the SPA, the resource consumption is not much. As far as I can tell, it only takes up a few MB of memory because it is deployed through Nginx. On the other hand, SSR takes up quite a bit of memory, I must say it is the most memory-consuming among the running services. Simply because it is deployed through a Node.js server, and Node.js consumes a lot of memory. Both Vue and Nuxt.js are supported by Pages, so I can easily migrate these two pages. But before migrating, it is necessary to evaluate the required features.

First is the admin panel page, since it is built with Vue and uses SPA, migrating it to Pages isn't too complicated. All that needs to be done is to change the environment variables to receive the configuration during build.

As for the blog interface page, I came up with an idea: instead of using SSR as it is currently, why not try converting it to SSG? This way, I can use a command to generate the website into static HTML files and upload them to any host that supports static pages, not just Cloudflare Pages. Moreover, the speed will be much faster compared to regular SSR because there is no need to query the database and generate HTML code for each visit. Thinking about it, I spent a whole week modifying the Nuxt code to work well with SSG mode.

Finally, earlier this week, I completed the basic process of moving the two interface pages to Pages. Of course, there are still a few bugs that need to be fixed, but currently, it fully meets the reading and search needs of everyone.

Benefits of Moving

I can save some resource costs for the admin panel and blog interface pages. Although it is not much, now I don't have to worry too much about server overload or any errors that may occur, as it can still function normally since Cloudflare has stored all the HTML.

The CI/CD process is shortened and less complicated. Previously, I needed to write many scripts to support this through Gitlab CI and Docker, but now, anytime I push code to Gitlab, it can build automatically.

I have switched DNS to Cloudflare to take advantage of their CDN infrastructure and data caching mechanism. The blog now has an impressive access speed.

Lastly, Web in the EDGE may become a trend in the future. Meaning you don't have to deploy a specific server to run a website, you can just run it through services like Pages. To learn more about this trend, readers can visit https://deno.com/blog/the-future-of-web-is-on-the-edge.

What's Left to Do

Although the majority of the migration process went smoothly, there are still some issues that need time to address.

The first is undiscovered or discovered but non-impactful errors. This issue only requires time to fix, or if readers discover any errors, they can leave a comment to inform me and I will fix them.

There are some features that become unnecessary or disabled after migrating to Pages, and they need to be removed to avoid confusion in the future.

Another issue is that there is no way to activate a notification after a successful or failed Page deployment. Hopefully, Cloudflare will soon add a notification feature or, at least, I will run a curl command along with the npm run generate command to send notifications to Telegram.

That's what's currently on the agenda. In the long run, it is to completely eliminate the need for a server and move all services to the cloud. Then I will be able to set up an automated system and not worry too much about infrastructure.

Premium
Hello

The secret stack of Blog

As a developer, are you curious about the technology secrets or the technical debts of this blog? All secrets will be revealed in the article below. What are you waiting for, click now!

As a developer, are you curious about the technology secrets or the technical debts of this blog? All secrets will be revealed in the article below. What are you waiting for, click now!

View all

Subscribe to receive new article notifications

or
* The summary newsletter is sent every 1-2 weeks, cancel anytime.

Comments (1)

Leave a comment...
Avatar
Noi Truong1 year ago
Cho mình hỏi, khi bạn chuyển blog sang SSG thì blog có full static được không? các bài viết có được generate thành html tĩnh không hay vẫn phải chạy runtime rendering lại post mỗi khi có request mới?
Reply
Avatar
Xuân Hoài Tống1 year ago
Các bài viết của mình được generate thành các file .html luôn, đồng nghĩa với việc nó sinh ra hết nội dung của bài viết trong file đó luôn. Còn một vài phần cần dữ liệu động, như phần bình luận thì mình vẫn sử dụng JavaScript để tải như bình thường 😄
Scroll or click to go to the next page