DEV Community: Ayesha Iftikhar

Compressing PDFs entirely in the browser with pdf.js, OffscreenCanvas and a Web Worker

Ayesha Iftikhar — Wed, 30 Sep 2026 13:38:22 +0000

Most "free online PDF compressor" sites work the same way: you upload the file, a server shrinks it, and you download the result. When I built PDF Perfect, I wanted the opposite. The file should never leave the user's device, and you should be able to prove that by switching your Wi-Fi off halfway through.

Merging, splitting and rotating in the browser are fairly well-trodden: pdf-lib copies pages between documents without re-encoding anything. Compression was the interesting part, so this post covers how it works, the trade-offs I accepted, and what I'd do differently.

Why compression is hard in the browser

Desktop tools like Ghostscript compress a PDF by walking its object tree: they downsample embedded images, subset fonts and strip unused objects. That needs a full PDF rewriter with image codecs, and there's no small, well-maintained JavaScript library that does all of it.

What the browser does have is an excellent PDF renderer (Mozilla's pdf.js, the one inside Firefox) and a fast JPEG encoder (canvas.convertToBlob). So the approach is:

Render each page to a canvas at a chosen scale.
Encode the canvas as a JPEG at a chosen quality.
Build a new PDF where each page is just that image.

It's a rasterising compressor. For scans and photo-heavy PDFs, which are the files people actually need to shrink, it works very well. For text documents it has a real cost, which I'll come back to.

Keeping it off the main thread

Rendering 200 pages blocks the main thread for a long time, so it all runs in a Web Worker. Workers don't have a DOM, but they do have OffscreenCanvas, and pdf.js can render into one.

The core loop, simplified from the real worker:

const pdf = await pdfjsLib.getDocument({ data: arrayBuffer }).promise;
const outDoc = await PDFDocument.create(); // pdf-lib
const canvas = new OffscreenCanvas(1, 1);
const ctx = canvas.getContext("2d");

for (let i = 1; i <= pdf.numPages; i++) {
  const page = await pdf.getPage(i);
  const viewport = page.getViewport({ scale });

  canvas.width = viewport.width;
  canvas.height = viewport.height;
  await page.render({ canvas, viewport }).promise;

  const jpeg = await canvas
    .convertToBlob({ type: "image/jpeg", quality })
    .then((b) => b.arrayBuffer());

  const image = await outDoc.embedJpg(jpeg);
  outDoc
    .addPage([image.width, image.height])
    .drawImage(image, { x: 0, y: 0, width: image.width, height: image.height });

  postMessage({ type: "progress", progress: Math.round((i / pdf.numPages) * 100) });
}

const bytes = await outDoc.save();

A few details that matter more than they look:

One canvas, reused. The worker creates a single OffscreenCanvas and resizes it for each page, rather than allocating a new canvas per page, which keeps memory steadier on long documents.
Transfer, don't copy. The result goes back to the main thread as an ArrayBuffer in the transfer list, so a 300 MB output isn't duplicated.
A timeout. The main thread gives the worker 5 minutes. A tab that silently spins forever on a huge file is worse than a clear error.
The pdf.js worker inside my worker. pdf.js wants its own worker script. Importing it with Vite's ?url suffix and setting GlobalWorkerOptions.workerSrc works in both dev and production builds, but the server has to send .mjs files as text/javascript. My Apache host didn't, and the result was a very confusing production-only failure.

Quality levels and "compress to 1 MB"

The three presets are just (JPEG quality, render scale) pairs:

Preset	JPEG quality	Scale
High Quality	0.82	1.0
Balanced	0.6	0.85
Maximum	0.4	0.75

Users often don't care about presets, though. They have a job portal that says "max 2 MB". So there's a Target File Size mode, which walks a ladder of five settings from best to smallest and returns the first result that fits:

for (const settings of ladder) {
  const result = await attempt(settings);
  if (result.compressedSize <= targetBytes) return result;
  smallest = !smallest || result.compressedSize < smallest.compressedSize ? result : smallest;
}
return smallest; // couldn't hit the target; show how close we got

A binary search over quality would need fewer passes. But with only five meaningful steps and output size that doesn't change smoothly with quality, the linear ladder was simpler to reason about and gives the user the best-looking file that fits.

The trade-off I had to be honest about

Rasterising means text in the compressed file is no longer text. You can't select it, search it or have a screen reader read it, and at scale 1.0 very small print looks soft when you zoom in. For a scanned form that's irrelevant. For a 40-page contract exported from Word, it's a real loss, and the file can even get bigger, because vector text is tiny.

So the UI shows before and after sizes up front, the docs say plainly what happens, and the guides recommend re-exporting text documents from the source app instead. I'd rather lose a user to the right tool than hand them a worse file.

Proving the file never leaves

"We don't upload your files" is easy to claim, so I wanted it to be easy to check:

Offline test: load a tool, turn off Wi-Fi and process a file. It still works. (For compression, pdf.js is lazy-loaded, so run it once while online first.)
Network tab: process a file with DevTools open. You'll see the page, fonts and analytics, and no request with a body anywhere near your file's size.

The How it works page walks through both tests.

What I'd do next

A structural compressor for text PDFs: downsample only the embedded images with pdf-lib and leave the text alone. It's harder, but it's the right answer for Word exports.
A streaming approach for very large files, since the whole document is currently held in memory.

If you want to try it, the compressor is here. I'd love feedback from anyone who's fought pdf.js in a worker too.

I'm the developer of PDF Perfect.

How Uber Computes Estimated Time of Arrival (ETA)

Ayesha Iftikhar — Sat, 26 Sep 2026 17:05:43 +0000

Short answer: how does Uber compute ETA?
Uber snaps noisy GPS pings to the road network (map matching), finds candidate routes on a road graph, and predicts travel time for each road segment with machine-learning models fed by real-time traffic. It then sums and corrects the route estimate, models its uncertainty, and keeps refreshing the Uber ETA as the trip progresses.

For a ride-hailing platform like Uber, Estimated Time of Arrival (ETA) is not a cosmetic feature. It is a core real-time decisioning system that directly influences conversion, matching quality, pricing behavior, and user trust.

An inaccurate ETA increases cancellations, reduces marketplace liquidity, and weakens reliability perception. At scale, even small percentage errors can have measurable business impact.

1. Problem Definition

Uber must estimate two different time horizons:

Pickup ETA: Time for the driver to reach the rider
Trip ETA: Time from pickup to destination

This happens under hard constraints: real-time computation, global traffic variability, sparse-data regions, continuous driver movement, and noisy GPS streams.

2. System Architecture Overview

Uber's ETA stack is a multi-layer system where each layer solves a specific sub-problem:

Data ingestion for live GPS and traffic signals
Map matching to align noisy locations to roads
Routing to generate path candidates
Feature engineering for temporal and contextual signals
Machine learning for segment-level travel-time prediction
Online serving for low-latency ETA responses

3. Data Inputs that Drive Accuracy

ETA quality depends on combining real-time, historical, and context-rich features:

**Real-time: **driver GPS, speed vectors, congestion, live traffic feeds
Historical: time-of-day trends, weekday patterns, road speed distributions, weather and holiday effects
Contextual: city density, special events, roadwork, and construction zones

4. Map Matching and Graph Routing

Raw GPS is inherently noisy. Before route estimation, positions are snapped to likely road segments using probabilistic map-matching methods, often including Hidden Markov Model-style inference.

The road network is then represented as a weighted directed graph where intersections are nodes and road segments are edges. Edge weights represent traversal time, not just distance.

Routing engines apply optimized shortest-path methods such as Dijkstra, A*, and contraction hierarchies with real-time weight updates from live traffic.

5. Travel Time Estimation via Machine Learning

Uber does not rely purely on static shortest-path output. It predicts travel time at the road-segment level using machine learning.

Current speed and congestion
Historical average segment speed
Time bucket and day effects
Weather condition
Road type and intersection complexity

Model evolution typically progresses from linear models to gradient boosting and then to deep temporal architectures that better capture time-series traffic dynamics.

6. Pickup ETA Computation Logic

Pickup ETA is often harder than trip ETA because drivers may be moving, finishing another ride, or deviating in dense traffic.

Pickup ETA ≈ Remaining current segment time + optimal route time + intersection delay adjustments.

The system also computes uncertainty margins so user-facing predictions are robust under variance.

7. Real-Time Recalculation

ETA is continuously refreshed every few seconds using:

Live GPS deltas
Congestion updates
Route deviation detection
Dynamic re-routing logic If traffic spikes or route conditions shift, ETA is recomputed immediately.

8. Offline Training and Online Serving

The architecture is split into two stages for scale and latency:

Offline: train on billions of trips, build region-specific models, retrain continuously
Online: low-latency inference with feature store lookups, caching, and approximate serving optimizations Production latency targets are strict, commonly sub-100 ms for inference pathways.

9. Uncertainty and Confidence Modeling

ETA systems must model variance explicitly rather than output a single deterministic number.

Confidence intervals
Percentile ETAs (for example P50 and P90)
Error calibration curves
This enables messaging like "Arriving in 5–7 minutes" and improves perceived reliability.

10. Global Scaling Challenges

City diversity: each city has distinct traffic behavior requiring regionalized models
Sparse regions: cold-start geographies rely more on map priors, traffic APIs, and transfer learning
GPS distortion: urban canyons require smoothing with Kalman filters and trajectory correction

11. Continuous Improvement Loop

Uber improves ETA with a feedback cycle that combines A/B testing, prediction error pipelines, cancellation correlation analysis, and operational feedback from drivers and riders.

When ETA error patterns correlate with cancellation spikes, retraining and feature adjustments are prioritized.

12. Business Impact

Accurate ETA improves ride acceptance, reduces cancellations, raises driver utilization, and increases marketplace efficiency. Even small gains in ETA precision create significant revenue and trust impact at global scale.

13. Lessons for Engineers

Do not rely only on shortest-path algorithms
Predict at segment level instead of full-route level
Separate heavy offline ML from low-latency online serving
Model uncertainty explicitly, not optionally
Retrain continuously as traffic behavior shifts

Key Takeaway

Uber's ETA engine is far more than distance divided by speed. It is a distributed, real-time intelligence system combining graph theory, probabilistic modeling, deep learning, and infrastructure engineering under strict latency and reliability constraints.

How I Built a Local-First Journaling App with Flutter, Drift and Firebase

Ayesha Iftikhar — Wed, 23 Sep 2026 12:33:13 +0000

I build Mindleau, a free brain-dump journal and mood tracker for iOS and Android. From day one, it had one hard requirement: you should be able to open the app and start writing without creating an account or having an internet connection.

Journal entries are some of the most private things people type, and the moment someone needs to empty their head is probably the worst possible time to show them a sign-up form.

That requirement shaped the whole architecture. Here's how it's built, including the tradeoffs.

The stack

Flutter for iOS and Android from one codebase
Drift (typed SQLite) as the source of truth
Firebase Auth + Cloud Firestore for optional background sync
provider + ChangeNotifier / ValueNotifier for state. No Riverpod, no Bloc. The app is small enough that it didn't need them.

The central rule: the UI never talks to Firestore. Every screen reads and writes through a single repository, and the repository only writes to SQLite. Sync happens afterwards, in the background.

Screens ──► SanctuaryRepository ──► Drift (SQLite)   ◄── source of truth
                      │
                      └──(background)──► SyncService ──► Firestore

1. Every syncable table carries its own sync state

Instead of a separate outbox table, each syncable row records whether it has been pushed:

class BrainDumpRows extends Table {
  IntColumn get id => integer().autoIncrement()();
  TextColumn get remoteId => text().nullable()();
  TextColumn get content => text()();
  DateTimeColumn get createdAt => dateTime()();
  DateTimeColumn get updatedAt => dateTime().clientDefault(DateTime.now)();
  DateTimeColumn get deletedAt => dateTime().nullable()();   // soft delete
  TextColumn get mood => text()();
  TextColumn get focusTagsCsv => text()();
  TextColumn get syncStatus =>
      text().withDefault(const Constant('synced'))();       // pending_create | pending_update | synced
  DateTimeColumn get lastSyncedAt => dateTime().nullable()();
}

Four columns carry the sync logic:

remoteId maps the local autoincrement ID to the Firestore document ID.
updatedAt drives conflict resolution (more on that below).
deletedAt is a tombstone. Hard-deleting a row locally would leave nothing to tell the server it's gone.
syncStatus makes "what still needs pushing?" a single indexed query.

2. Writes are local and synchronous; sync is fire-and-forget

Saving a brain dump is a plain SQLite insert, marked as pending, followed by a sync attempt the UI doesn't wait for:

Future<int> saveBrainDump({
  required String content,
  required String mood,
  required List<String> focusTags,
}) async {
  final now = DateTime.now();
  final id = await _database.into(_database.brainDumpRows).insert(
        BrainDumpRowsCompanion.insert(
          content: content,
          createdAt: now,
          updatedAt: Value(now),
          mood: mood,
          focusTagsCsv: _encodeList(focusTags),
          syncStatus: const Value('pending_create'),
        ),
      );
  unawaited(syncNow()); // never blocks the save
  return id;
}

The user sees their entry immediately. Whether sync then succeeds, fails, or can't run because there's no signal changes nothing on screen.

3. Sync is pull-then-push, last-write-wins

syncNow() runs the same steps every time:

Future<void> syncNow() async {
  if (!await _canAttemptCloudSync()) return;
  try {
    if (!await service.ensureSignedIn()) return;
    await _pullRemoteChanges(service);
    await _pushPreferences(service);
    await _pushBrainDumps(service);
    await _pushMoodCheckIns(service);
    await _pushLearnProgress(service);
  } catch (error, stackTrace) {
    log('Sync failed', error: error, stackTrace: stackTrace);
  }
}

Pulling first means remote changes (from another device) are merged before local pending rows are pushed. The merge rule is plain last-write-wins on updatedAt:

final existing = await (_database.select(_database.brainDumpRows)
      ..where((t) => t.remoteId.equals(remoteId)))
    .getSingleOrNull();

// Local copy is newer: keep it; it'll be pushed next.
if (existing != null && existing.updatedAt.isAfter(remoteUpdatedAt)) return;

Tradeoff: LWW can lose an edit if the same entry is changed on two offline devices. For a personal journal, where one person is almost always on one device at a time, that's acceptable. A CRDT would add a lot of complexity to prevent a conflict that almost never happens here.

4. Anonymous auth first, email later

"No account required" and "sync across devices" pull in opposite directions. Firebase anonymous auth solves it:

On first sync, the app signs in anonymously. The user never sees a form, but their data has a stable users/{uid} path in Firestore.
If they later add an email, the anonymous account is linked to an email-link credential, so the same UID and data carry over.
On a new phone, the email link restores that account.

If anonymous auth is disabled or unreachable, ensureSignedIn() returns false and sync is skipped. The app keeps working from SQLite either way.

5. Bound every network call

This bug took me a while to understand. Firestore and Firebase Auth calls have no built-in timeout. On a flaky connection that isn't fully offline, an await can hang forever, leaving a spinner with no way out. Every network call now goes through one wrapper:

const _networkTimeout = Duration(seconds: 15);

Future<T> _withTimeout<T>(Future<T> action) => action.timeout(
      _networkTimeout,
      onTimeout: () => throw const NetworkTimeoutException(),
    );

Because the UI never awaits sync, a timeout just means "try again later". When connectivity comes back, a listener calls syncNow() and every row that isn't synced goes up.

6. Migrations are part of the product

Moving from "local only" to "local-first with sync" meant adding sync columns to tables that already held real user data. Drift's MigrationStrategy makes this explicit and versioned:

@override
int get schemaVersion => 5;

@override
MigrationStrategy get migration => MigrationStrategy(
      onUpgrade: (m, from, to) async {
        if (from < 2) {
          await m.addColumn(brainDumpRows, brainDumpRows.remoteId);
          await m.addColumn(brainDumpRows, brainDumpRows.syncStatus);
          // ...
        }
        if (from < 5) {
          await m.createTable(stillnessSessionRows);
        }
      },
    );

One lesson: SQLite won't add a NOT NULL column without a SQL-level default, and Drift's clientDefault only exists in Dart. So updated_at needed a raw ALTER TABLE ... ADD COLUMN updated_at INTEGER NOT NULL DEFAULT 0 for the rows already on users' phones.

7. Not everything has to sync

Guided stillness sessions (a timer-based breathing pause) are local-only on purpose. They only feed streaks and the 30-day heatmap, so syncing them wasn't worth the extra code and the extra data leaving the device. Deciding what not to sync is part of the privacy design.

What I'd do differently

Start with the sync columns. Adding them in migration v2 was avoidable.
Store tags as a JSON column, not CSV. CSV was quick at first and has been awkward to work with since.
Write the timeout wrapper on day one. Hanging awaits are the worst kind of offline bug because they only show up on bad networks, never at your desk.

Takeaways

If you're building anything personal (journals, habit trackers, notes), local-first is less work than it sounds:

Make SQLite the source of truth.
Put a syncStatus and updatedAt on every row.
Never let the UI wait for the network.
Use anonymous auth so "no account" and "sync" can coexist.

You can see the result in Mindleau. It's free on iOS and Android, and you can start writing without signing up. Questions about the sync design are welcome in the comments.

How to Generate a Secure JWT Secret Key in Node.js

Ayesha Iftikhar — Wed, 13 Aug 2025 10:35:52 +0000

When working with JWT (JSON Web Tokens) in a Node.js application, your secret key plays a critical role in signing and verifying tokens.

A weak or predictable key can compromise your application’s security, so it’s best to generate it randomly.

Here’s how you can easily create a strong JWT secret key using Node.js:

Add Script to package.json

Open your package.json and inside the "scripts" section, add:

"scripts": {
  "jwt-key": "node -e \"console.log(require('crypto').randomBytes(32).toString('hex'))\""
}

Run the script
In your terminal run:

npm run jwt-key

You will get:

a47f7c20e4f9a87c6d0af6e6c8c4bc25d2a8e7c4a9f5c30f72db7d9a48f1c3d2

Copy that string into your .env file.

If you use this often, you can even combine it with a direct write to .env so it replaces the JWT secret automatically:

"scripts": {
  "jwt-key": "echo JWT_SECRET=$(node -e \"console.log(require('crypto').randomBytes(32).toString('hex'))\") > .env"
}

This will overwrite .env with the new secret each time.