DEV Community: Henry Lee

Same-Origin or Bust: Proxying No-Code Pages Through Nginx So Our Analytics Could See Them

Henry Lee — Sun, 25 Oct 2026 23:15:37 +0000

We had a nice setup: designers built marketing and feature pages in Framer, and we embedded them into our product. It cut a lot of development time.

Then we adopted a new analytics tool, and that setup quietly stopped working for it. This post walks through why, the options we weighed, and how we ended up with a dedicated Nginx reverse proxy — after validating the idea in Express first.

The new requirement: behavior analytics

If you run a product, you know how valuable it is to see where users click and how they move through a page.

We already used GTM and Hotjar, but we wanted more precise behavioral data, so we adopted Beusable, a tool that visualizes clicks, mouse movement, and scroll flow.

The catch: it only works inside iframes under strict conditions.

The tracked page must be same-origin with the host page.
The embedded page must not send CSP headers that block its script.

The problem: Framer's hosting

Framer hosts every project at project-name.framer.com. You can embed that page in an iframe, but it's a different domain — so it's not same-origin, and the analytics tool can't capture any events inside it.

Missing data for the pages we were actively iterating on meant weaker decisions about how to improve them.

Options we considered

1. A subdomain

Idea: point something like framer.example.com at Framer.

Problem: browsers treat subdomains as different origins too.

💡 Same-origin policy: if the protocol, host, or port differs, the browser treats it as a different origin and restricts access. example.com and framer.example.com are separate origins.

2. Self-host Framer's export

Idea: export HTML/CSS from Framer and serve it ourselves.

Problem: designers edit these pages often. Every change would need a manual re-export, which is hard to automate and expensive to maintain.

3. A reverse proxy

A reverse proxy serves external content through our own domain, which solves the same-origin problem. After talking it through with our backend engineers, we went this way and compared three ways to build it:

(a) Load balancer rules at the infra layer. Every new proxy route would need an infra engineer. Slow, and hard to scale as a team practice.

(b) Middleware in our existing Express server. Our React app already ran behind Express for SEO injection, so a proxy middleware would work. But Express was already serving static files and acting as an API server. Adding proxying would pile on complexity and blur responsibilities further.

(c) A dedicated Nginx proxy. ✅ This is what we chose.

Why Nginx

Nginx is a lightweight, fast, flexible web server and reverse proxy — good at static files, load distribution, and proxying.

Pros

Drops easily into our existing Docker-based deploy pipeline.
Pulls a cross-cutting concern out of Express, so responsibilities are clearer.
Security headers (HSTS, X-Frame-Options, X-Content-Type-Options) are a few lines of config.
Bot blocking, IP restrictions, and rate limiting are available when needed.
Gzip and proxy caching come almost for free.

Cons

One more piece of config to maintain. We judged the benefit worth the added complexity.

Validate fast, then refactor

We wanted two things at once: keep the service stable and improve the architecture. So we didn't jump straight to Nginx.

First, we added reverse-proxy logic directly in Express. That let us confirm the analytics tool worked through a proxy without touching infrastructure.
Once that was proven, we refactored step by step and moved the proxy into Nginx.

Prove the effect quickly, then clean up the structure.

The new container layout

Before: the container forwarded external traffic to port 80, where Express answered everything directly.

After:

Nginx listens on port 80 inside the container.
Express moved to an internal port (e.g. 3000).
Nginx routes by path: proxy to Express, serve static files directly, or proxy to Framer.

Serving static files directly:

location /static/ {
  alias /path/to/static/;

  expires 1d;
  add_header Cache-Control "public, max-age=86400, s-maxage=86400";

  gzip_static on;
  try_files $uri =404;
}

Proxying Framer pages so they're same-origin:

location /service/framer/ {
  proxy_pass https://your-project.framer.website/;
  proxy_set_header Host your-project.framer.website;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_ssl_server_name on;
  proxy_intercept_errors off;
}

Security headers:

add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "upgrade-insecure-requests" always;

Results

Analytics works. Framer pages are now served same-origin, so the heatmap tool tracks them.
Security: HTTPS, CSP, and HSTS headers live in one place.
Performance: static files are served by Nginx with caching and gzip.
Maintainability: each layer has one job, so problems can be debugged independently.

What started as "make the analytics tool work" ended as a cleaner, more secure, more observable architecture.

I'm Henry, a frontend engineer focused on React, Next.js, TypeScript and Playwright E2E testing. This post is adapted from a write-up I originally published in Korean. I'm open to frontend roles abroad — let's connect on LinkedIn or see my work on GitHub.

We Built Our Own Frontend Take-Home Assignment — and Graded It with Playwright

Henry Lee — Sun, 25 Oct 2026 23:15:36 +0000

When teams design a frontend take-home, the first idea is usually a CRUD app. We decided to go one step further.

This post covers why we designed our assignment as a simulation of real work instead of a pure implementation task, and what we learned building an E2E auto-grading pipeline for it.

"Isn't CRUD enough?"

Our evaluation criteria were clear from the start:

Turning data into UI — how well a candidate presents a complex data structure as a usable interface
Handling the unhappy path — consistent UX under network delays and API failures
Code written for collaborators — clear naming, sensible comments, consistent patterns
Sustainable architecture — a structure that bends with changing requirements

A plain CRUD app can't really surface most of those. So we set a different goal:

Let candidates experience the problems they'd actually face on our team.

That cuts both ways. Candidates get to see how we solve problems here. We get to see how they'd solve problems once they joined. It shows attitude and structural thinking better than raw implementation speed.

Designing a real-work simulation

We took the UI, API, and logic from one of our production services and rebuilt a simplified version of it. Not a mock-up — a compressed set of situations frontend engineers hit every week:

Lists and conditional rendering
Data caching and transformation
Slow and failing API responses
Responsive UI and state management
Multi-step forms with validation

Hidden traps in the requirements 🧩

A task that only asks for features is boring and teaches nothing. So we deliberately planted situations you'd meet in real development:

Planted situation	What it reveals
Random API errors	Error handling
Response delays	Loading states and UX design
Incomplete data	Data shaping and caching strategy
Dependent API calls	Async flow control and structure

These aren't gotchas. They're signals for how flexibly someone handles real-world mess.

Why we auto-grade with E2E

We used to install, run, and check every submission by hand. It was slow, and every reviewer graded a little differently.

Goals for automation:

A consistent grading baseline
Fast pass/fail on minimum requirements
Less repetitive checking → more time for actual code review

We split grading into two tiers:

Tier	What it covers
Core requirements	Required features
Open-ended	UX improvements, error handling, optimization

Less experienced candidates can still finish the core tier. Experienced candidates can show what they've got in the open-ended tier. The E2E suite grades the two tiers separately.

Mock API instead of a local server

We considered shipping a real server candidates would run locally, but chose a mock API instead:

No setup tax. No env config, database, or auth just to start building UI.
A simple, stable response model. We define exactly the fields the frontend needs.
A small project. No server to maintain means a faster start and less upkeep.

"Build fast, verify fast" — a mock API fit that best.

Making failure reproducible with MSW

Real services always have a success path and a failure path. Against a real API, failure cases are surprisingly hard to reproduce on demand.

So we built the MSW (Mock Service Worker) handlers to read environment variables:

ERROR_RATE=10
DELAY_TIME=300

With that, a share of requests fail on purpose and every response gets artificial latency. In E2E runs and QA we can test realistic scenarios like "10% failure rate" and "300 ms network delay," and check exactly how the UI reacts when things go wrong.

The grading pipeline

Candidate PR → Docker build → E2E run → JSON report → Grade

The candidate opens a PR against the grading branch.
CI builds and boots the app in Docker.
Playwright runs the suite at desktop and mobile viewports in parallel.
Results are saved as a JSON report.
The report is parsed into a grading summary and stored as a CI artifact.

Reviewers just open the branch to see the grade — no local setup required.

Recap

What we gained

Noticeably faster candidate screening
Interviews refocused on code review and technical conversation
Candidate feedback along the lines of "it felt like I was briefly part of the team"

What's next

Browser performance logging
Automated screenshot comparison in E2E

We still value the process of solving a problem over a perfect answer. A hiring assignment shouldn't just be an evaluation; it should be time for both sides to get to know each other.

From an Express SPA to Next.js 16: A Test-First Strangler Fig Migration of a Shared Auth System

Henry Lee — Sun, 25 Oct 2026 23:15:34 +0000

I worked on a frontend team that owned the unified account system for a group of creative-industry products. One login, several services — so if auth breaks, everything breaks.

This post walks through how we moved that system from an Express-served React SPA to Next.js 16 (App Router) without a big-bang rewrite, and why the very first thing we wrote wasn't application code, but E2E tests.

The starting point

The account system was a React SPA served by an Express server. It had run reliably for years, but the Express server had slowly absorbed too many responsibilities, all hard-coded in one place:

API routing
Session management
Injecting meta tags for SEO

Two problems followed:

Poor separation of concerns. One server doing everything meant every change touched the same tangled code.
Rising maintenance cost. With every new feature it was unclear where code should live. Components were mixed together, and business logic was tightly coupled to UI.

Big bang vs. strangler fig

Option 1 — Full rewrite (big bang). Start over and switch everything at once. The problem: several products depended on this login. A one-shot cut-over meant breaking compatibility everywhere at the same moment. The outage risk was too high.

Option 2 — Incremental migration (Strangler Fig pattern). Keep the old system running and move traffic over piece by piece.

Staying compatible while switching safely mattered more than anything else, so we chose the strangler fig.

Step zero: E2E tests before any code

After choosing an incremental migration, the first thing we did was reach 100% E2E coverage of V1's key user flows.

The scariest thing when you build a replacement is "something that used to work doesn't anymore." Login, sign-up, password reset, social login, linking legacy accounts — if any one of those breaks, users feel it immediately.

So we documented every critical V1 flow as a Playwright test.

// e2e/auth.spec.ts
test('redirects to My Page after a successful login', async ({ page }) => {
  await page.goto('/v2/auth/login');
  await page.fill('[name="email"]', 'test@example.com');
  await page.fill('[name="password"]', 'password123');
  await page.click('button[type="submit"]');
  await expect(page).toHaveURL('/v2/mypage');
  await expect(page.locator('.user-email')).toContainText('test@example.com');
});

test('locks the account after 5 failed attempts', async ({ page }) => {
  for (let i = 0; i < 5; i++) {
    await page.fill('[name="password"]', 'wrong');
    await page.click('button[type="submit"]');
  }
  await expect(page.locator('.error-message')).toContainText('locked');
});

test('sends legacy accounts to the account-linking page', async ({ page }) => {
  // resultCode 203 case
  await page.fill('[name="email"]', 'legacy@example.com');
  await page.click('button[type="submit"]');
  await expect(page).toHaveURL(/\/v2\/auth\/connect/);
});

These tests became the spec for V2. When V2 code passed them, we could say with confidence: "it behaves exactly like V1."

TDD on top of the E2E suite

Red — run the E2E suite against V2. It fails, because there is no V2 code yet.
Green — write just enough code to pass.
Refactor — clean up while the tests stay green.

This guaranteed "whatever worked in V1 works in V2" at the level of user scenarios, not just at the level of code.

Why Next.js 16 + App Router

The biggest pain in the old Express server was that it had no TypeScript. Maintaining it without type safety kept getting harder.

Option	Pros	Cons
NestJS	TypeScript, structured backend	Backend only; frontend still managed separately
Go + Echo	Fast, type-safe	Hard for a frontend team to own
Next.js App Router	TypeScript by default, full-stack	Tied to the React ecosystem

We seriously considered writing a new backend in NestJS or Go. What decided it was ownership: the frontend team was going to maintain this system. Next.js let us:

Write UI and API in the same language (TypeScript)
Keep everything in one repo
Use one deployment pipeline
Share types between React components and API logic

The hardest part: session compatibility

V1 used express-session backed by Redis. The new Next.js app had to read and write the exact same sessions, so a user logged in on a V1 page stays logged in on a V2 page, and vice versa.

express-session uses a signed cookie:

Cookie name: connect.sid
Cookie value: s:{sessionId}.{HMAC_signature}

And the session lives in Redis like this:

{
  "cookie": {
    "originalMaxAge": 604800000,
    "secure": true,
    "httpOnly": true,
    "path": "/",
    "sameSite": "none"
  },
  "user": {
    "id": "user123",
    "email": "user@example.com",
    "access_token": "eyJhbG...",
    "refresh_token": "eyJhbG..."
  }
}

On the Next.js side we implemented the same contract: parse connect.sid, verify the signature with the same secret, and read/write the same Redis key. With that in place, V1 and V2 share one session, and users get the same experience no matter which version serves the page.

API strategy: switch over gradually

For now, V2 pages still call V1's API through a Next.js rewrite proxy:

// next.config.js
async rewrites() {
  return {
    beforeFiles: [
      {
        source: '/front/api/:path*',
        destination: `${EXPRESS_API_URL}/front/api/:path*`,
      },
    ],
  };
}

V1's Express API talks to Keycloak, and V2's API Routes are already implemented to talk to Keycloak the same way. In a later phase, Next.js talks to Keycloak directly and Express drops out of the path.

Why we kept Nginx in front

In V1, Nginx served static files and Express handled the API. In V2, Next.js handles both pages and API. So why keep Nginx?

Because it still does infrastructure-level work that doesn't belong in application code:

Role	What it does
Security headers	HSTS, X-Frame-Options, CSP, etc.
WAF	Web application firewall
Rate limiting	Request limits, DDoS mitigation

server {
  listen 443 ssl http2;

  add_header X-Content-Type-Options "nosniff" always;
  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header Strict-Transport-Security "max-age=31536000" always;

  limit_req zone=api burst=20 nodelay;

  location / {
    proxy_pass http://nextjs:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
  }
}

Nginx keeps its mature, battle-tested security features; the application logic lives in Next.js and TypeScript.

Results

Stability backed by E2E tests. We hit 100% E2E coverage of V1's key flows first and built V2 against it, so the migration shipped without regressions in those flows.
Full compatibility. V1 and V2 share the same session. Users see no difference.
Type safety. With Zod + TypeScript, runtime errors dropped significantly. API responses and form data are typed end to end.

Phase 1 is complete. Next: turn on all V2 API Routes and retire the legacy code step by step.

Takeaway

The one thing we optimized for was stability, so we wrote the tests before the code. We documented every critical V1 flow as an E2E test and built V2 by making those tests pass.

"If the tests pass, it behaves like V1." That confidence is what made an incremental migration of a system everyone depended on actually feel safe.