How to Deploy a Low-Cost and High-Disaster-Tolerance Blog Website

Let's first talk about my experience. Recently, by building this blog website, I gained a deeper understanding of various website building knowledge and techniques, and I achieved great results through hands-on practice. Below, I will describe the overall process in detail.

Background

When I first started building this blog website, I wasn't very familiar with the frontend technology stack, so I initially chose the most widely used React framework to build the frontend project. Meanwhile, I also set up the backend SpringBoot service for data storage and access control. A separated frontend and backend project has many benefits. However, for a blog website, which mostly serves static resources and doesn't change frequently with minimal dynamic interaction, it is more suitable to adopt a static page generation (SSG) approach. So, after further researching the SSG technology stack, and based on my project needs, I migrated the blog project to a new setup, resulting in a noticeable improvement in website loading speed and user interaction experience, and the overall effect met expectations.

Technology Stack

Next.js
Vercel
AWS

What is SSG (Static Site Generation)?

SSG (Static Site Generation) is a website generation technique that pre-generates and stores HTML files of web pages as static files during the build phase. Unlike traditional dynamic rendering methods, SSG pages do not require backend processing or database queries when a user requests them; instead, they return static HTML directly, improving page load speed and stability.

Advantages of SSG:

Fast Loading Speed: Since the pages are static, the browser can directly load HTML and resources without requiring dynamic rendering by the server.
SEO-Friendly: Pages are generated with complete HTML during the build, which helps search engines crawl the site.
High Scalability: Static files can be deployed to global CDNs, allowing users to access the site quickly.
Strong Security: No runtime dependence on backend logic, reducing potential security vulnerabilities.

Suitable Scenarios:

Websites with relatively static content, such as blogs and documentation sites.
Websites that require optimization for initial load speed.
Websites with high SEO optimization needs.

Next.js Support for SSG

Next.js is a React-based framework that supports SSG with flexible rendering modes. Next.js provides powerful tools like getStaticProps and getStaticPaths to implement SSG.

Key Features:

getStaticProps:
- Used to fetch data required for the page during the build phase.
- The returned data will be injected into the page component's props to generate static HTML.
- Example:
```
javascript
export async function getStaticProps() {
    const data = await fetchData();
    return {
        props: { data },
    };
}
```

getStaticPaths:

Used to generate static pages for dynamic routes, such as blog detail pages.
During the build phase, HTML is generated for each page based on the returned paths.
Example:

javascript
export async function getStaticPaths() {
    const paths = getBlogPaths(); // Returns something like [{ params: { id: '1' } }]
    return {
        paths,
        fallback: false, // Or true
    };
}

Incremental Static Regeneration (ISR):

Next.js provides Incremental Static Regeneration (ISR) functionality, allowing developers to automatically update the generated static pages after the build.
Example:

javascript
export async function getStaticProps() {
    const data = await fetchData();
    return {
        props: { data },
        revalidate: 60, // Re-generate the page every 60 seconds
    };
}

How SSG Works:

During the build phase, getStaticProps and getStaticPaths are called to generate static HTML files.
When deployed, these HTML files are stored with other static resources on the server or CDN.
When users request the site, the content is returned directly from the CDN.

Vercel Support for SSG

Vercel is the official hosting platform for Next.js, providing highly optimized support for SSG and other rendering modes.

Key Features:

Global Distributed CDN:
- The static files generated by SSG can be deployed to Vercel's global CDN nodes, ensuring fast access.
Automatic Build and Deployment:
- Integrated with GitHub/GitLab, Vercel automatically rebuilds static pages after code updates.
Native ISR Support:
- Vercel natively supports Incremental Static Regeneration in Next.js, managing caching for real-time updates.
Preview Mode:
- Vercel supports Next.js Preview Mode, allowing developers to preview unpublished content changes.
Zero Configuration Optimization:
- Vercel automatically configures HTTP cache headers to ensure efficient caching and effective updates of static resources.

Workflow Integration:

Developers write code locally using Next.js.
Push the code to GitHub/GitLab.
Vercel detects the code update and triggers the build process:
- Runs getStaticProps and getStaticPaths to generate static pages.
- Deploys the HTML and resources to the global CDN.
When users access the site, content is quickly retrieved from the nearest CDN node.

Migration Process

Register an account on Vercel, choose a suitable blog template project, link it to GitHub, initialize the repository, and deploy it.
Modify the style based on the template and convert the original blog to markdown format, then deploy it.
Map the original domain to the new Vercel deployment.
Add GitHub workflow configuration to automate deployment to AWS S3 and use CloudFront for acceleration.

Technical Gains

Dual Domain Multi-Cloud Disaster Recovery

When mapping the domain, since the original domain was purchased from AWS, and the root domain purchased on AWS can only be mapped to AWS products and not external domains, an interesting idea came up. Considering that AWS offers a Free Tier and Vercel provides a free usage package, I came up with the idea of mapping the root domain blogofvictor.link to AWS S3 with CloudFront CDN acceleration, and modifying the GitHub workflow configuration to automate deployment to S3. At the same time, I mapped www.blogofvictor.link to the Vercel domain. This creates a low-cost, highly disaster-tolerant blog website. Both services are nearly free, and even if one cloud service completely fails, the blog website will still be displayed properly.

AWS CloudFront Routing Logic Issue

Since AWS S3 only handles static resource storage and lacks dynamic routing capabilities, and Next.js routing is based on client-side rendering, an issue arises when accessing specific blog pages where AWS would fail to redirect. After further investigation, I found that the issue lies in the routing logic of CloudFront Functions. The logic needs to be modified so that if the URI doesn't include a file extension, .html is added to the URI.
The corresponding function code is:

function handler(event) {
    var request = event.request;
    var uri = request.uri;

    // Check if the URI contains a file extension
    if (!uri.includes('.')) {
        // If URI doesn't contain an extension, try adding a .html suffix
        request.uri = uri + '.html';
    }

    return request;
}