🌐 Creating a Portfolio Site to host project links and walkthroughs

🎯 Project Overview

The creation of this site was the first project I worked on post-graduation. I wanted a centralized hub to showcase my projects, link to my GitHub and LinkedIn, and demonstrate practical DevOps skills. What started as a simple static site evolved into a comprehensive learning experience in web hosting, infrastructure management, and secure API integration.

🔄 Hosting Evolution

Phase 1: GitHub Pages

Technologies: GitHub Pages, Static HTML/CSS/JavaScript

I started with GitHub Pages as it was familiar territory from college coursework. This provided a solid foundation for understanding static site deployment and version control integration.

What I learned: Git-based deployment workflows, Jekyll basics, DNS configuration for custom domains, limitations of static hosting.

Phase 2: Self-Hosting (Raspberry Pi + Nginx + Cloudflare Tunnel)

Technologies: Raspberry Pi, Nginx web server, Cloudflare Tunnel, Linux server administration

To gain hands-on experience with server management, I transitioned to local hosting. This phase taught me the most about infrastructure:

  • Nginx configuration: Set up virtual hosts, configured SSL/TLS certificates, optimized static file serving
  • Cloudflare Tunnel: Bypassed ISP port blocking (80/443) by creating a secure tunnel from my Raspberry Pi to Cloudflare's edge network, eliminating the need for port forwarding
  • Linux administration: User permissions, systemd services, log monitoring, security hardening
  • Network architecture: Understanding reverse proxies, DNS propagation, CDN benefits

Challenges solved: ISP residential connection limitations, dynamic IP management, securing a publicly accessible home server.

Why I moved on: While successful, the Raspberry Pi lacked a UPS (uninterruptible power supply), leading to potential downtime during power fluctuations. Additionally, I wanted to repurpose the Pi for other projects and IoT experiments.

Phase 3: Cloudflare Pages (Current)

Technologies: Cloudflare Pages, Cloudflare Workers, Git integration, Serverless functions

Moving to Cloudflare Pages provided enterprise-grade hosting with minimal operational overhead:

  • Automatic deployments: Git push triggers immediate builds and deployments
  • Global CDN: Content served from edge locations worldwide for optimal performance
  • 99.99% uptime SLA: Eliminated availability concerns from home hosting
  • Zero maintenance: No server updates, patches, or infrastructure management needed

⚙️ Technical Implementation

API Integration: OpenWeather API

I integrated the OpenWeather API to display real-time weather data, providing practical experience with external API consumption and asynchronous JavaScript.

Security Challenge: Protecting API Keys

The primary challenge with client-side API calls is exposure of API keys in browser developer tools. I solved this using Cloudflare Workers:

Initial approach (Insecure):

// Direct API call from client - EXPOSES API KEY
fetch(`https://api.openweathermap.org/data/2.5/weather?q=London&appid=${API_KEY}`);

Solution: Cloudflare Worker as Proxy

I created a serverless function that acts as a secure intermediary:

// Cloudflare Worker (runs on edge servers)
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url)
  const city = url.searchParams.get('city')
  
  // API key stored in Worker environment variables (secure)
  const apiKey = OPENWEATHER_API_KEY
  const apiUrl = `https://api.openweathermap.org/data/2.5/weather?q=${city}&appid=${apiKey}`
  
  const response = await fetch(apiUrl)
  const data = await response.json()
  
  return new Response(JSON.stringify(data), {
    headers: { 
      'Content-Type': 'application/json',
      'Access-Control-Allow-Origin': '*' 
    }
  })
}

How it works:

  1. Client-side JavaScript calls my Worker endpoint (no API key exposed)
  2. Worker retrieves the API key from secure environment variables
  3. Worker makes the API request server-side
  4. Worker returns the weather data to the client

Benefits of this approach:

  • API key never exposed to client browsers
  • Request rate limiting can be implemented at the Worker level
  • Additional validation and sanitization of user input
  • Potential for response caching to reduce API calls

Difference from College Approach (dotenv)

In college, I used dotenv for environment variables in Node.js applications running on a server. However, this doesn't work for static sites where JavaScript runs entirely in the browser. The Cloudflare Worker solution provides server-side execution in a serverless environment, bridging the gap between static hosting and secure API access.

🏗️ Current Architecture

Deployment Pipeline:

  1. Code changes pushed to GitHub repository
  2. Cloudflare Pages detects commit via webhook
  3. Automated build process executes
  4. Site deployed to Cloudflare's global CDN
  5. Traffic routed through nearest edge location

Performance optimizations:

  • Static asset caching at edge locations
  • HTTP/2 and HTTP/3 support
  • Automatic image optimization

📚 Key Takeaways

  • Infrastructure as code: Understanding the tradeoffs between self-hosting and managed services
  • Security-first development: Never expose credentials client-side, always use server-side proxies for sensitive operations
  • Serverless architecture: Cloudflare Workers provide powerful edge computing without server management
  • DevOps fundamentals: CI/CD pipelines, automated deployments, monitoring and logging
  • Network engineering: DNS, CDNs, reverse proxies, and tunneling technologies

🚀 Future Enhancements

This site serves as my ongoing web development practice ground and project management hub. I plan to continuously update it as I learn new technologies and complete new projects.

  • Comment system: Implement a commenting feature (likely using a service like Disqus, utterances with GitHub issues, or a custom Cloudflare Workers solution) to gather feedback and engage with visitors
  • Project management dashboard: Expand the site to better organize and showcase my projects with filtering, search, and categorization features
  • Experimentation space: Use the site as a sandbox to practice new web development concepts, frameworks, and techniques as I encounter them
  • Iterative improvements: Continuously refine the design, user experience, and functionality based on my evolving skills and feedback from the community