DEV Community

Cover image for Case Study: Migrating to a Cloud-Synced, Edge-Secured AI Architecture After a Frontend Breach 🛡️☁️
Harun - solo dev
Harun - solo dev

Posted on

Case Study: Migrating to a Cloud-Synced, Edge-Secured AI Architecture After a Frontend Breach 🛡️☁️

In the rush to ship product, early-stage startups often make architectural compromises that accumulate severe technical debt. For HYNAWEB, a technology holding company building developer tools, that compromise resulted in a critical frontend API key exposure.

Within hours of deployment, our AI inference credits were drained by automated bots scraping our client-side JavaScript.

This incident forced an immediate, hard pivot in our infrastructure strategy. We didn't just patch the hole; we completely re-architected our flagship product, KODA (an AI coding mentor), into a cloud-synced, edge-secured SaaS platform.

This case study documents the 48-hour migration from a vulnerable, local-state frontend to an enterprise-grade, URL-agnostic cloud architecture.


🛑 The Incident: The Cost of Client-Side Secrets

Our initial deployment relied on direct client-side fetch requests to our LLM inference provider. The API key was embedded in the frontend bundle.

While this allowed for rapid prototyping and zero-backend deployment, it violated a fundamental security principle: Never trust the client. Automated scrapers detected the exposed key in the network tab, leading to immediate resource exhaustion.

The mandate from our engineering team was clear: Zero exposed secrets. Zero local-state lock-in.


🛡️ Phase 1: The Edge Proxy & Self-Healing Fallback

To secure our inference pipeline without provisioning traditional backend servers, we deployed a Cloudflare Worker to act as an edge proxy.

The Architecture:

  1. The frontend sends a POST request containing only the user's prompt and chat history to the Worker URL.
  2. The Worker intercepts the request, retrieves the API key from Cloudflare Environment Variables (Encrypted Secrets), and attaches it to the header.
  3. The Worker forwards the request to the inference provider and streams the response back to the client.

The Self-Healing Fallback Chain:

AI model endpoints frequently deprecate or hit rate limits. To ensure 99.9% uptime, we engineered a fallback array directly inside the Edge Worker:

const FALLBACK_MODELS = [
  "openai/gpt-oss-20b",
  "meta-llama/llama-4-scout-17b-16e-instruct",
  "llama-3.3-70b-versatile"
];
Enter fullscreen mode Exit fullscreen mode

If the primary model returns a 404 or 429 status, the Worker automatically cycles to the next model in the array. The frontend remains completely unaware of the failover, resulting in a seamless, self-healing user experience.


☁️ Phase 2: Cloud State Management (Supabase + RLS)

With the inference pipeline secured, we addressed the second major flaw: Local State Lock-in.

Previously, user chat histories, code vaults, and project submissions were stored in the browser's localStorage. If a user cleared their cache or switched devices, their data was lost.

We migrated our entire state layer to Supabase (Managed PostgreSQL).

The Schema Design:

  • conversations & chats: Normalized tables for multi-turn AI dialogues.
  • files: Encrypted storage for the user's Code Vault.
  • submissions: A global ledger for our Code Jam showcase.

Security via Row Level Security (RLS):

Instead of writing complex middleware to verify user ownership, we pushed authorization down to the database layer using Supabase RLS.

create policy "own conversations" on public.conversations 
for all using (auth.uid() = user_id) 
with check (auth.uid() = user_id);
Enter fullscreen mode Exit fullscreen mode

This guarantees that even if a malicious actor bypasses the frontend and queries the database directly, PostgreSQL physically rejects any attempt to read or mutate rows they do not own.


🔄 Phase 3: Cross-Domain Continuity (The "Aha" Moment)

The true test of a cloud-native SaaS architecture is its decoupling from the frontend URL.

During our migration testing, we deployed KODA to a temporary staging URL (temp.netlify.app) and our main production URL (prod.netlify.app).

When a user authenticated on the staging link, initiated a chat, and then navigated to the production link and logged in, the exact same chat history was instantly available.

Because the state is tied to the User UUID in the cloud database rather than the browser's local storage or the domain name, KODA achieved true cross-device, cross-domain continuity. The frontend URL is now merely a "window" into the cloud state.


🚀 Phase 4: Viral Infrastructure via Database Triggers

To drive user acquisition without manual intervention, we engineered a viral referral loop directly into the database schema.

The profiles table includes a referred_by column and a referral_count integer. We attached PostgreSQL triggers (bump_referrals) that automatically fire on INSERT or UPDATE events.

When User B signs up using User A's referral link, the frontend updates User B's referred_by field. The database trigger instantly catches this, increments User A's referral_count, and evaluates boolean flags to automatically promote User A to "Ambassador" or "Champion" status.

Result: A fully automated, zero-compute growth engine.


📱 The Constraint Thesis: Hardware-Driven Elegance

HYNAWEB operates under a unique constraint: our core engineering and deployment workflows are executed entirely from mobile hardware (a $150 Android device).

This constraint prohibits the use of heavy local development environments, Docker containers, or complex CI/CD pipelines. It forces our engineering team to rely exclusively on managed, serverless, and edge-native tools:

  • Compute: Cloudflare Workers & Vercel Edge
  • Database: Supabase (Postgres)
  • Hosting: Netlify Edge CDN

Far from being a limitation, this hardware constraint breeds architectural elegance. It forces the adoption of modern, globally distributed infrastructure that scales to zero and costs nothing until real user traffic arrives.


📌 Conclusion

The frontend API breach was the catalyst KODA needed to evolve from a local prototype into a resilient, cloud-synced SaaS product.

By leveraging Edge computing for secret management, PostgreSQL RLS for authorization, and cloud-state for cross-device continuity, HYNAWEB has established an infrastructure foundation capable of supporting enterprise scale.

The server is dead. The edge is the backend. The cloud is the state.

Explore the ecosystem: https://hynaweb.vercel.app/

Architecture #Serverless #Supabase #Cloudflare #WebAssembly #HYNAWEB #CaseStudy #SaaS

Top comments (0)