DEV Community: RjS

System Architecture of React Playground: What Actually Happens Behind the Scenes

RjS — Fri, 01 May 2026 13:55:40 +0000

In the previous blog, I talked about what I built and the problems I faced.

This time, I want to break down the architecture, not in a dry, textbook way, but in the same way I understood it while building it.

The Mental Model

At a high level, this is what’s happening:

The frontend behaves like an IDE
The backend acts like a coordinator
Workers actually run your code
Redis connects everything
S3 stores user solutions

So let’s go step by step.

Step 1: Writing Code (Frontend Sandbox)

When you type JSX in the editor:

Monaco Editor captures the code
Babel (standalone) transpiles JSX → JavaScript
That JS is injected into an iframe

Why iframe?

Because if your code crashes, I don’t want the entire app to crash with it.

So the execution happens inside an isolated environment:

Separate DOM
Separate JS context

React and ReactDOM are loaded via CDN, and then your component is rendered inside that iframe.

This gives you instant feedback.

Step 2: Submitting Code

Now comes the important part.

When you click “Submit”:

The raw JSX (not transpiled code) is sent to the backend
Backend creates a solutionId
That ID is returned to the frontend

At this point, nothing has been executed yet.

Step 3: Why WebSockets?

After getting the solutionId, the frontend:

Opens a WebSocket connection
Registers itself using that ID

Why not polling?

Because polling would look like:
“Is it done?” → repeat forever

Instead:

Backend will push the result when ready

This removes unnecessary load and makes the system real-time.

Step 4: The Queue

Here’s where the architecture becomes interesting.

Instead of executing code directly in the backend:

The backend pushes the job into a queue (BullMQ)
The job contains: code + metadata

Why?

Because executing user code is:

Slow
Unpredictable
Potentially dangerous

If we did this inside the main server:

It would block everything
One bad job could kill performance

So we separate execution.

Step 5: Worker Picks It Up

The worker continuously listens to the queue.

As soon as a job arrives:

Worker takes the job
Starts processing

This is completely asynchronous.

The backend doesn’t wait.

Step 6: Execution Pipeline

The worker does this:

Takes JSX string
Transpiles it again using Babel
Launches Puppeteer
Injects the code into a real browser environment
Simulates user actions

We don’t just check output.

We simulate behaviour.

For example:

Find a button
Click it
Check if UI updates correctly

This is why frontend transpilation is not enough.

We need:

A DOM
An event loop
Real browser behavior

Node.js alone cannot do this.

Puppeteer solves that.

Step 7: Isolation

Running user code is risky.

So we isolate at multiple levels:

Each execution runs in a new Puppeteer page
No shared state between runs
Worker is separate from the backend process

Even if something goes wrong, it stays contained.

Step 8: Returning the Result

Once execution is done:

Worker marks job as completed (BullMQ)
Backend listens to queue events
Backend finds the correct socket using solutionId
Emits result via WebSocket

Frontend receives it instantly and updates UI.

Step 9: Redis

Redis handles:

Queue storage (BullMQ)
Job events (completed/failed)
Caching layer (for faster reads)

Earlier, I was using raw Pub/Sub.

But it required:

Manual channel management
Manual message parsing

Switching to BullMQ simplified everything:

Built-in lifecycle events
Retry handling
Cleaner architecture

Step 10: Storage with S3

Another problem:

Where do we store user code?

If we store it directly in MongoDB:

It becomes heavy
Not scalable

So instead:

Code is stored in AWS S3
Only the file key is saved in DB

When needed:

Backend generates a signed URL
Frontend uses that to fetch code

This ensures:

Security (no public access)
Scalability
Clean separation

Step 11: The Full Flow

User writes code
Code runs in iframe (preview)
User submits
Backend returns solutionId
Frontend opens WebSocket
Backend pushes job to queue
Worker picks a job
Code executed via Puppeteer
Result emitted via queue event
Backend sends result via WebSocket
Frontend updates UI

Key Design Decisions

1. Double Transpilation

Frontend:

For preview

Backend:

For validation with real DOM

2. Queue-Based Execution

Prevents blocking
Enables scaling workers independently

3. Puppeteer Instead of Node Execution

Needed for DOM + interaction
Ensures accurate validation

4. WebSockets Instead of Polling

Real-time updates
Lower load

5. S3 Instead of DB Storage

Better scalability
Cleaner architecture

Designing a Real-Time React Playground with Workers, Queues, and WebSockets

RjS — Sat, 04 Apr 2026 13:52:22 +0000

I built a full-stack SaaS project, an interactive playground to learn and practice React. Think of it as LeetCode, but for React.

Of course, the usual full-stack features are there (authentication, etc.), but that’s not the interesting part.

What is interesting is the system design and the problems I ran into while building and deploying it.

What Makes This Project Different

This project involves several non-trivial concepts:

Pub/Sub architecture
Queues and workers
WebSockets for real-time updates
Babel (standalone) for transpilation
Puppeteer for code execution
Docker for environment consistency
AWS for deployment
Isolated sandbox for safe execution

Core Flow

Here’s how the system works:

1: User submits code
2: Backend returns a solutionId
3: Frontend registers a WebSocket using the solutionId
4: Worker starts execution
5: Worker finishes execution
6: Redis publishes the result
7: Backend receives the result
8: Backend emits the result via WebSocket
9: Frontend receives the result and updates the UI

Why Transpile Twice?

You might wonder:

If we already transpile on the frontend, why do it again on the backend?

After transpiling on the frontend, if we pass that transpiled code to the backend, we lose the ability to properly simulate user interactions on it.

For validation, we need to simulate events (like clicks). To do that reliably:

We take the original user code
Transpile it again on the backend
Execute it inside Puppeteer
Trigger events programmatically

This ensures we can accurately simulate interactions and validate behaviour.

Sandbox Execution

Running arbitrary user code is dangerous.

To handle this:

Code is executed inside a controlled Puppeteer environment
Each execution happens in a new isolated page
This prevents malicious scripts from affecting the system

Deployment Challenges

Problem 1: Puppeteer Dependencies

Puppeteer requires Chrome and several system-level dependencies.

Most backend hosting platforms don’t provide these out of the box.

Solution: Docker

Docker allowed me to define a consistent environment with:

Chrome dependencies
Node environment
All required libraries

Now the app runs the same everywhere.

Problem 2: Render Deployment Failure

Initially, I deployed the backend on Render.

But I kept getting:

package dotenv not found

I tried:

Reinstalling dependencies
Modifying the Dockerfile
Adding installation scripts

Nothing worked.

Switching to Railway

I moved to Railway, and guess what? It worked immediately.

But there was a catch:

Only 1 month free trial

So this wasn’t a long-term solution.

Moving to AWS

This is where things got real.

I had theoretical knowledge of AWS, but this was my first practical experience.

What I did:

Launched an EC2 instance
Configured a static IP
Set up security groups
Learned SSH (the hard way)
Cloned the backend repo
Configured environment variables

This process involved a few trials and errors, but it worked.

Problem 3: No HTTPS

AWS provides a public DNS, but it’s HTTP, not HTTPS. This becomes a problem because if the frontend is served over HTTPS, the browser expects all backend requests to also use HTTPS; otherwise, it blocks them due to mixed content security restrictions.

To get HTTPS:

I needed a domain
I didn’t want to spend money on a hobby project

Solution: Render as a Proxy

I reused Render, but differently.

Instead of hosting the backend:

I created a proxy service
It forwards requests from a secure Render URL → AWS backend

So now:

Users hit a secure HTTPS endpoint (Render)
Requests are forwarded to my AWS server

Problem 4: Keeping the Backend Updated

After deployment, another issue appeared:

When I push new code, how does AWS get it?

Initially, the answer was:

SSH into the instance
Pull the latest code manually

Clearly not scalable.

Solution: CI/CD

Time to implement CI/CD (this, too, I only knew in theory before this).

What I did:

Wrote a simple YAML pipeline
Automated pulling the latest code on deployment

Note: I still have a lot to learn about Docker and CI/CD.
This setup is basic but functional.

Final Result

Everything is now working end-to-end:

Secure access via proxy
Scalable job processing via queues
Real-time updates via WebSockets
Safe execution using Puppeteer + isolation
Automated deployment via CI/CD

Try It Out

👉 https://reactpg.vercel.app

What’s Next

I’ll be writing another blog soon covering:

System architecture in depth
Detailed flow diagrams
Design decisions and trade-offs

Closing Thoughts

This project forced me to move from theory → practice in multiple areas:

System design
DevOps
Deployment
Debugging real-world issues

And honestly, that’s where most of the learning happened.