Wanblog

Hello everyone! And welcome to the very first post of WanBlog. I thought there was no better way to start this blog than by explaining how the blog itself was built.

This project started as a simple idea: what if I built my own blog from scratch? It quickly turned into an excuse to learn more about cloud architecture, deployment strategies, authentication, caching, and even AI-assisted development.

So before getting into the technical details, let's start with the basics.

What is WanBlog?

WanBlog (as its name implies) is my personal blog where I'll share knowledge, ideas, and things I find interesting. I don’t plan to limit it to just technology. Although that will probably be the main focus, but rather use it as a place to think, learn, and build in public.

This blog is also an experiment.

An experiment in:

• Building systems from scratch
• Learning cloud architecture hands-on
• Mixing AI tools with manual engineering
• And documenting the entire process

Why build a blog from scratch?

There’s a well-known saying in software engineering: don’t reinvent the wheel.

And it's true, most of the time you're better off using something that already exists and is battle-tested. But there’s also something valuable in building something yourself, even if it already exists.

You gain a deeper understanding of how things actually work.

You learn where complexity lives. You understand tradeoffs. You see what abstractions hide.

And most importantly — you build it your way.

Also, what better way to learn how something works than by building it yourself?

How was WanBlog created?

Planning

I knew I wanted to create a blog, but I didn’t really know where to start. My first idea looked something like this:

The idea was fairly straightforward:

• An EC2 backend acting as an API
• An MVC-style application generating static HTML
• Generated files uploaded to S3
• CloudFront serving the static content

In theory, this would give me:

• Full control
• Static performance
• Simple hosting
• Low cost

But I quickly realized something:

I didn’t actually know AWS well enough to confidently build this.

So I kept exploring.

During an AWS event (AWS Student Community Day) hosted here in my city, I saw a presentation about Amplify. I had used Amplify before, but honestly, I didn’t really understand what it was doing under the hood.

So I decided to give it another try. And the architecture evolved into this:

Now the application lives entirely within the Amplify ecosystem.

The stack looks like this:

• Hosting: Amplify
• Authentication: Cognito (groups + roles)
• Frontend: NextJS + React
• Rendering: SSG + Incremental Static Regeneration (ISR)
• Backend: Amplify backend definitions (CDK in TypeScript)
• Permissions: IAM + Cognito groups
• Data: Serverless models

This approach turned out to be significantly easier to maintain. The backend became mostly infrastructure definitions, and the frontend remained a normal React + NextJS application with AWS integrations.

This made authentication, permissions, and data access much easier to reason about.

Implementation

With the architecture decided, the next step was getting everything running.

The first thing I did was create an IAM user with the required permissions for development. This was probably one of the hardest parts — deploy, fail, add permission, redeploy, repeat.

But that’s part of the learning process.

Once the AWS roles were configured, I started setting up the Amplify backend.

You can take a look at the backend repository here:
https://github.com/NexWan/wanblog-backend

I decided to separate frontend and backend into different repositories. This made deployments cleaner and allowed me to iterate independently on infrastructure and UI.

After getting the backend running, I moved on to structuring the frontend. Since the app uses NextJS, I was able to leverage static generation and incremental regeneration for blog posts, which gives a nice balance between performance and flexibility.

AI-Usage

This project also became an experiment in AI-assisted development.

I relied heavily on AI tools while building the site — but not in a “build me a blog” way. Instead, I used them as collaborators for specific tasks.

The main tools I used were:

• Claude Code / Codex
  Used for backend definitions, data integration, and architecture iteration.

• Stitch AI (Google)
  Used for initial frontend layout and design direction.

• Stitch MCP + Antigravity (Gemini)
  Used to translate designs into components and refine UI structure.

• And obviously… myself :)
  Handling architecture decisions, debugging, integration, and the final implementation.

The interesting part was not just using AI, but orchestrating multiple tools together while still keeping control over the system.

Final Thoughts

WanBlog started as a simple idea: build a blog.

It ended up becoming:

a cloud architecture experiment an AI-assisted development workflow a serverless deployment project and a place to document everything I learn

And honestly, this is just the beginning.

There are still many things I want to improve:

• caching strategies
• search
• tagging system
• editor experience
• analytics
• performance optimizations

But that’s part of the journey, and exactly what this blog is for.

If you're reading this, thanks for being part of the very first step.

P.S: You can take a look at the full Frontend repo too in my Github :)
https://github.com/NexWan/wanblog-frontend