A senior engineer’s take on the classic client-side vs. server-side debate, sparked by a privacy-focused Next.js PDF tool. Learn when to optimize the client, when to go hybrid with serverless, and when to build a dedicated backend.

Your Client-Side App is Awesome… And a Ticking Time Bomb.

I remember this one project from about five years ago. We were building a slick, in-browser tool for real estate agents to touch up property photos. It was all client-side, all JavaScript. We thought we were geniuses—no server costs for image processing! The demo for the stakeholders went great… on our high-end development machines. Then came the pilot launch. The first support ticket was from an agent, bless his heart, running the app on a five-year-old Chromebook. He tried to upload a batch of 20 high-res photos, and his browser didn’t just freeze; it took the entire OS down with it. That day, I learned a hard lesson: the user’s browser is not your server. It’s an unpredictable, resource-constrained environment you have zero control over.

So, when I saw a Reddit post about a brilliant, 100% client-side PDF tool built with Next.js, my “senior engineer senses” started tingling. It’s an awesome achievement, especially for privacy. But it lives on the same knife’s edge we did. Let’s talk about why this happens and how you, the architect, can navigate it.

The “Why”: The Unreliable Narrator

The root cause of this dilemma isn’t about code quality; it’s about the execution environment. When you build a 100% client-side application, you are outsourcing your entire compute layer to your end-users. You’re making a bet that their device—be it a brand new M3 MacBook Pro or a budget Android phone with 50 Chrome tabs open—can handle the load.

This works beautifully for simple tasks. But for something CPU or memory-intensive like processing a 100-page scanned PDF, you’re rolling the dice. The UI thread gets blocked, the page becomes unresponsive, and the user experience falls apart. You’ve created a great tool that’s unusable for a chunk of your audience.

Solution 1: The “Stay the Course” Triage

The first option is to double down on the client-side approach but build in safeguards. This is for when privacy is the absolute number one feature and you’re willing to trade performance for it.

How to do it:

• Offload to Web Workers: This is non-negotiable. Any heavy lifting MUST be moved off the main UI thread and into a Web Worker. This prevents the page from freezing, allowing you to show a loading spinner or progress bar while the PDF magic happens in the background.
• Leverage WASM: For truly heavy lifting, JavaScript might be too slow. Compiling a robust library written in Rust or C++ to WebAssembly (WASM) can give you near-native performance right in the browser. Libraries like pdf-lib are great, but for intense operations, WASM is your ace in the hole.
• Manage Expectations: Be honest with the user. If they upload a massive file, display a message: “This is a large file and may take a few minutes to process on your device.”

Here’s a conceptual example of dispatching a task to a worker:

// in your main component:
const myWorker = new Worker('pdfProcessor.js');
const largePdfFile = document.getElementById('pdf-upload').files[0];

// Send the file to the worker, don't process it here!
myWorker.postMessage({ file: largePdfFile, action: 'MERGE' });

// Listen for the result
myWorker.onmessage = (e) => {
  console.log('Worker finished!', e.data.processedFileUrl);
  // Update UI with the result
};

Warning: This path is a slippery slope. Feature creep is your enemy. As soon as marketing asks for “just one more thing,” like server-side OCR scanning, this entire architecture breaks down. Know its limits.

Solution 2: The “Pragmatic Architect” Hybrid Play

This is my preferred approach for 90% of cases. You get the best of both worlds: keep simple, privacy-sensitive tasks on the client, and offload the heavy, complex jobs to a scalable, ephemeral backend like a serverless function.

How to do it:

You identify the operations that are too much for a browser. Let’s say it’s merging more than 5 documents or running optical character recognition (OCR). These tasks get sent to an API Gateway endpoint that triggers an AWS Lambda or Google Cloud Function.

Your frontend code might look something like this:

async function handleHeavyPdfTask(file) {
  const formData = new FormData();
  formData.append('pdf', file);

  // Call your serverless function endpoint
  const response = await fetch('https://api.your-domain.com/process-pdf', {
    method: 'POST',
    body: formData, 
    // Add auth headers, etc.
  });

  if (!response.ok) {
    // Handle server-side error
    return;
  }

  const result = await response.json();
  // Do something with the processed file URL from the response
}

Solution 3: The “We’re a Real Business Now” Rearchitecture

Sometimes, the requirements evolve so much that a client-side or hybrid model is just putting a band-aid on a bullet wound. You need durable storage, user accounts, asynchronous job queues, and guaranteed processing. It’s time to build a dedicated backend service.

How to do it:

This is the “nuclear option.” You build a proper backend API. The frontend becomes a thin client that primarily just uploads the file and polls for status.

1. The client uploads the PDF to a secure pre-signed S3 URL.
2. The S3 upload triggers an event that puts a message into an SQS queue.
3. A fleet of EC2 or Fargate containers (your `pdf-processor-worker-fleet`) pulls messages from the queue.
4. The worker processes the file, saves the result back to S3, and updates a status in a database like `prod-db-01` (e.g., DynamoDB or Postgres).
5. The frontend polls a `/job-status/:jobId` endpoint to check for completion.

Pro Tip: The moment you do this, you become a custodian of user data. Your privacy policy is no longer just a boilerplate page. You are now responsible for data encryption (in transit and at rest), access controls, and retention policies. This isn’t just a technical change; it’s a business and legal one.

There’s no single “right” answer. The 100% client-side tool is elegant and perfect for its privacy-focused niche. But as engineers and architects, our job is to see the road ahead. We need to know when to optimize, when to go hybrid, and when to tear it all down and build the robust, scalable backend the business will eventually need. The trick is knowing which stage you’re in.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions