Welcome to my blog! My name is Thorsten Fey, and this is your hub for in-depth technical insights and practical guides from the world of modern software development.

Here, I share my experiences and solutions from my Tech Journey as a Self-Taught Developer. The focus is clearly on robust, practical solutions that work in real-world scenarios.

What You Will Find Here:​

• Backend & APIs: Detailed guides and deep dives into Java and the Spring Boot framework.
• Frontend & UI: Modern application development with Angular and TypeScript.
• DevOps & Infrastructure: Everything about Docker containerization, GitHub Actions, and migration to serverless architectures like Google Cloud Run (GCP).
• Databases: Best practices, performance optimization, and advanced usage of PostgreSQL.
• Polyglot Programming: Occasional forays into new languages like Rust and Python.

Whether you are looking for migration guides, ready-to-use code snippets, or transparent insights into real-world challenges—here you will find the answers that will help you on your own development journey.

Happy reading and exploring!

This post documents a production-ready routing pattern for Firebase Hosting that avoids redirects, preserves clean URLs, and keeps API tooling intact.

It originated from a LinkedIn discussion after repeatedly seeing /api/** traffic handled via 302 redirects — a workaround that breaks DX, auth flows, and OpenAPI tooling at scale.

The setup uses Firebase Hosting strictly as a router and delegates API traffic to a minimal Nginx proxy running on Cloud Run.

graph TB
    A[Browser] -->|Request| B[Firebase Hosting]
    B -->|/docs| C[Static Content - Docusaurus]
    B -->|/api/**| D[Cloud Run - Nginx Proxy]
    D -->|upstream| E["/api/portal"]
    D -->|upstream| F["/api/leetcode"]
    
    style A fill:#e1f5ff
    style B fill:#fff4e6
    style C fill:#e8f5e9
    style D fill:#fce4ec
    style E fill:#f3e5f5
    style F fill:#f3e5f5

Why this pattern​

Firebase Hosting cannot proxy arbitrary external URLs while keeping the same origin.

Redirects solve this superficially, but introduce new problems:

• broken API tooling
• leaking infrastructure details
• SPA router interference
• brittle frontend workarounds

This pattern solves routing at the infrastructure layer instead.

Discussion​

This pattern sparked a broader discussion on LinkedIn around API routing in serverless setups.

👉 Join the discussion on LinkedIn

This entry summarizes the key learnings from migrating a Spring Boot monolith to a cost-effective, serverless architecture on Google Cloud Run.

The project involved tackling real-world challenges like dynamic $PORT handling, optimizing CI/CD with GitHub Actions for GCP, and resolving complex DNS/SSL handshake conflicts.

Key Takeaway​

Serverless demands a complete mindset shift regarding infrastructure assumptions.

Read the full, detailed post on my LinkedIn profile here: Full Post on LinkedIn

Click the link above to read the full, detailed post on my LinkedIn profile!