Welcome to the first post on Hakim!

When I set out to build this platform, my goal was simple: I didn't just want a static portfolio. I wanted to build a production-grade, highly scalable tech ecosystem that reflects the engineering standards I apply in my professional work.

But before we dive into the code, let's step back and look at the bigger picture. The internet is a fascinating, complex machine. When you type abdullahhakim.me into your browser and press enter, a lot of heavy lifting happens in the milliseconds before the screen renders.

Let’s trace the complete journey of your request—from your browser to my server and back—and look at the architecture that makes it happen.

Phase 1: The Internet's Phonebook (DNS)

The internet doesn't understand English; it understands IP addresses (like 192.168.1.1).

When you type abdullahhakim.me into your URL bar, your browser first needs to find the IP address of the server hosting my platform. To do this, it queries the Domain Name System (DNS). Think of DNS as the phonebook of the internet.

For this project, I use Cloudflare to manage my DNS. Cloudflare operates a massive global edge network. When you ask for abdullahhakim.me, Cloudflare’s nearest server intercepts the request and instantly returns my server's IP address. This global distribution ensures the resolution happens incredibly fast, no matter where you are in the world.

Phase 2: The Secret Handshake (HTTPS & TLS)

Once your browser has the IP address, it doesn't just start sending data blindly. First, it establishes a secure connection.

Your browser initiates a TLS (Transport Layer Security) Handshake with my server. During this handshake, they exchange cryptographic keys and agree on a secure encryption protocol. This is what gives my website the https:// prefix and the little padlock in your browser.

Even though this is a personal blog, ensuring that all data in transit is encrypted is a non-negotiable security standard. Read Privacy Policy

Phase 3: The Traffic Cop (Host & Nginx Reverse Proxy)

Now that a secure connection is established, your browser sends an HTTP GET request.

This request travels across the internet and arrives at my host server—a Virtual Private Server (VPS). But it doesn't hit the application code directly. First, it meets Nginx.

Nginx acts as a Reverse Proxy. You can think of Nginx as the highly-trained traffic cop at the entrance of my server. It intercepts the incoming public traffic and performs several critical tasks:

1. Security & Headers: It strips malicious payloads and attaches necessary security headers.

2. Routing: It looks at the request and decides which internal Docker container should handle it (e.g., routing /api traffic to the backend, and everything else to the frontend).

3. Efficiency: It can compress responses and manage connection pooling to keep the server from getting overwhelmed.

Once Nginx approves the request, it forwards it to the internal network. Here is a snippet of my actual nginx.conf routing traffic to the Next.js frontend and .NET backend:

# Frontend (Next.js)
    location / {
     proxy_pass http://web:3000;
     proxy_http_version 1.1;
     proxy_set_header Upgrade $http_upgrade;
     proxy_set_header Connection "upgrade";
     proxy_set_header Host $host;
     proxy_set_header X-Real-IP $remote_addr;
     proxy_cache_bypass $http_upgrade;
 }
# Backend API (.NET 10)
    location /api {
    proxy_pass http://api:5000;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
 }

Phase 4: Inside the Ecosystem (The Architecture)

This is where the engineering really shines. The request is now inside my server, interacting with an ecosystem built for scalability, maintainability, and speed.

Here is why I chose this specific architecture:

1. The Frontend: Next.js & React 19

If your request is for a web page, Nginx routes it to my frontend container.

I built the user interface using Next.js and React 19, styled with Tailwind CSS 4.0.

* Why Next.js? Server-Side Rendering (SSR). Instead of sending a blank page and forcing your browser to build the HTML via JavaScript, Next.js pre-renders the HTML on the server. This results in blazing-fast load times and perfect SEO—crucial for a blog.

Here's a look at how the Next.js page.tsx fetches and renders a blog post on the server:

export async function generateMetadata({ params }): Promise<Metadata> {
  const { slug, locale } = await params
  const post = await getPostBySlug(locale, slug)
  
  if (!post) return {}
  
  return createMetadata({
    title: post.title,
    description: post.excerpt,
    locale
  })
}

async function Page({ params }) {
  const { slug, locale } = await params
  const post = await getPostBySlug(locale, slug)

  if (!post) notFound()

  return (
    <>
      <BlogHeader post={post} />
      <article dir={post.isRtl ? 'rtl' : 'ltr'}>
        <Mdx contentJson={post.contentJson} />
      </article>
      <Suspense>
        <CommentSection slug={slug} postId={post.id} />
      </Suspense>
    </>
  )
}

2. The Backend: .NET 10 & Clean Architecture

If your frontend needs data (like fetching this blog post), it makes an API call to the backend.

The core engine of Hakim is an ASP.NET Core Web API running on .NET 10. I structured this backend strictly using Clean Architecture and the CQRS (Command Query Responsibility Segregation) pattern via MediatR.

* Why Clean Architecture? In enterprise software, coupling business logic to your database or UI framework is a recipe for technical debt. Clean Architecture ensures a strict separation of concerns. The Domain layer has zero dependencies. This makes the codebase highly testable, resilient to change, and easy to maintain as the project grows.

For example, when fetching a post, the request is handled by a MediatR IRequestHandler that checks the Redis cache before querying PostgreSQL with a compiled Entity Framework Core query:

public class GetPostBySlugQueryHandler(IAppDbContext context, ICacheService cache)
                          : IRequestHandler<GetPostBySlugQuery, PostDetailDto?>
{
    // High-performance EF Core Compiled Query
    private static readonly Func<DbContext, Slug, string, Task<CompiledPostResult?>> _getPostCompiled =
        EF.CompileAsyncQuery((DbContext db, Slug slug, string culture) =>
            db.Set<Post>()
            .AsNoTracking()
            .Where(p => p.Slug == slug)
            .Select(p => new CompiledPostResult(/* Mapping */))
            .FirstOrDefault());

    public async Task<PostDetailDto?> Handle(GetPostBySlugQuery request, CancellationToken cancellationToken)
    {
        var cacheKey = $"post-{request.Slug}-{culture}";
        var cachedPost = await _cache.GetAsync<PostDetailDto>(cacheKey, cancellationToken);
        
        if (cachedPost is not null) return cachedPost;

        // Fallback to database using the compiled query
        var result = await _getPostCompiled((DbContext)_context, new Slug(request.Slug), culture);
        
        if (result is null) return null;
        
        // ... format postDetail ...
        
        await _cache.SetAsync(cacheKey, postDetail, TimeSpan.FromMinutes(10), cancellationToken);
        
        return postDetail;
    }
}

3. The Data Layer: PostgreSQL & Redis

When the .NET API needs to retrieve this post, it talks to the database layer.

* PostgreSQL: Serves as the primary relational database, ensuring data integrity for posts, comments, and users.

* Redis: Used as a high-performance, in-memory cache. If a blog post is frequently accessed, the backend will fetch it from Redis in microseconds rather than querying the PostgreSQL database, dramatically reducing latency.

All of these components are Dockerized, meaning they run in isolated, easily deployable containers.

The Return Trip

Once the .NET API fetches the blog post from PostgreSQL (or Redis), it formats the data as JSON and sends it back to the Next.js frontend. The frontend renders the beautiful UI you are looking at right now, Nginx compresses the final HTML, and it travels back through the secure TLS tunnel to your browser.

All of this happens in a fraction of a second.

Wrapping Up

Building this platform wasn't just about throwing a template online. It was an exercise in applying professional engineering standards—from CI/CD pipelines in GitHub Actions to microservices and reverse proxies—to a personal project.

This is just Part 1. In future posts in this thread, I will be diving deeper into specific components of this ecosystem:

* How I structured the CQRS pattern in .NET 10.

* How the AI-driven resume tailoring microservice works.

* How I automated my deployment with GitHub Actions and Docker.

Stay tuned for the next deep dive!