DEV Community: deepak_dev

Building an Ephemeral, Zero-Database Document Generator in Vanilla/Modern JavaScript

deepak_dev — Thu, 10 Sep 2026 06:02:36 +0000

If you've ever searched for a biodata format online, you know the drill: sketchy templates, watermarked PDFs, or forms that ask you to sign up before letting you download anything containing your name, birth date, and family details. When I set out to build BiodataKit, a tool for generating a biodata for marriage document, the first architectural decision wasn't which framework to use — it was whether to use a backend at all. Spoiler: I didn't.

This post is a breakdown of how BiodataKit compiles fully custom, multi-layout documents entirely inside the browser, with zero server round-trips, zero stored PII, and zero database.
Architecture Overview: The Ephemeral Data Pipeline

The core question I kept asking myself was: why spin up Postgres, an ORM, auth, and a storage bucket just to shuffle around names, addresses, photos, and family details for the ninety seconds it takes someone to fill out a form and hit download?

For a document generator, persistence is a liability, not a feature. Every row you store is a row you have to secure, back up, and eventually explain in a breach disclosure. So the pipeline looks like this:

Input → form state lives in memory (React state / a reducer, nothing else)
Transform → state renders directly into a live-preview DOM node
Output → that DOM node gets rasterized to PNG/PDF client-side
Cleanup → all references, object URLs, and state are discarded on refresh or navigation

Nothing ever leaves the tab unless the user explicitly clicks "Download." That single constraint gives you three things for free: zero cloud database costs, instant user trust (you can tell people their data never hits a server, and mean it), and a genuinely simpler ops story — there's no backend to page you at 2 AM.

Deep Dive 1: Managing Schema-Agnostic Dynamic Inputs

The trickiest part isn't the export — it's the form. A biodata document isn't a fixed schema. Users want to add custom fields (a "Rashi" or "Gotra" field for astrological/cultural context), delete defaults they don't need, and reorder entire sections. That means you can't model the form as a flat object with hardcoded keys. You need an array-of-objects schema with stable IDs, mutated immutably.

Here's a simplified version of the reducer I use:

type FieldType = "text" | "date" | "textarea" | "select";

interface BiodataField {
  id: string;          // stable, generated once (crypto.randomUUID())
  label: string;
  value: string;
  type: FieldType;
  isCustom: boolean;    // user-injected vs. default field
}

type FieldAction =
  | { type: "ADD_FIELD"; payload: Omit<BiodataField, "id"> }
  | { type: "UPDATE_FIELD"; payload: { id: string; value: string } }
  | { type: "REMOVE_FIELD"; payload: { id: string } }
  | { type: "REORDER_FIELDS"; payload: { fromIndex: number; toIndex: number } };

function fieldsReducer(state: BiodataField[], action: FieldAction): BiodataField[] {
  switch (action.type) {
    case "ADD_FIELD":
      return [...state, { id: crypto.randomUUID(), ...action.payload }];

    case "UPDATE_FIELD":
      return state.map((f) =>
        f.id === action.payload.id ? { ...f, value: action.payload.value } : f
      );

    case "REMOVE_FIELD":
      return state.filter((f) => f.id !== action.payload.id);

    case "REORDER_FIELDS": {
      const next = [...state];
      const [moved] = next.splice(action.payload.fromIndex, 1);
      next.splice(action.payload.toIndex, 0, moved);
      return next;
    }

    default:
      return state;
  }
}

The key insight: because every field carries a stable id independent of its array position, reordering and deleting never causes React to misattribute state to the wrong — a bug that's brutally easy to introduce if you key your list by array index instead.

Deep Dive 2: The Browser Export Engine (DOM → Canvas → PDF/PNG)

This is where most "just use html2canvas and call it a day" tutorials fall apart in production. The live preview is a real DOM tree — styled with CSS, using web fonts, clip-path for circular vs. rounded-rectangle profile photos, and dynamic color palette overrides via CSS custom properties. Rasterizing that faithfully takes real work.

The two problems that bit me hardest:

Retina blur — if you rasterize at 1x scale, everything looks fine on a standard display and soft/blurry on any Retina or high-DPI screen.
External image + SVG serialization — tags pointing to external or blob URLs, and inline SVG icons, silently fail to render on canvas if you don't wait for them to fully decode first.

Here's a trimmed-down version of the actual export helper:

async function exportNodeToImage(node, filename = "biodata.png") {
  // 1. Wait for every image inside the node to finish decoding.
  const images = Array.from(node.querySelectorAll("img"));
  await Promise.all(
    images.map((img) =>
      img.complete ? Promise.resolve() : new Promise((res) => (img.onload = img.onerror = res))
    )
  );

  // 2. Scale for High-DPI displays instead of trusting default 1x rendering.
  const scale = Math.max(window.devicePixelRatio || 1, 2);

  const canvas = await html2canvas(node, {
    scale,
    useCORS: true,          // needed for cross-origin profile images
    backgroundColor: "#ffffff",
    logging: false,
  });

  // 3. Convert canvas to a blob, not a base64 string, to avoid huge memory spikes.
  canvas.toBlob((blob) => {
    if (!blob) return;
    const url = URL.createObjectURL(blob);

    const link = document.createElement("a");
    link.href = url;
    link.download = filename;
    link.click();

    // 4. Critical: revoke the object URL after the download fires.
    setTimeout(() => URL.revokeObjectURL(url), 1000);
  }, "image/png");
}

For PDF export, the same canvas gets handed to jsPDF, sized against the canvas's pixel dimensions divided by the scale factor — otherwise your PDF page size balloons to match the 2x/3x raster resolution instead of the actual document size.

The Quirks: High-DPI Scaling, Memory Leaks, and Mobile Layout Challenges

A few production lessons worth stealing:

devicePixelRatio isn't optional. Hardcode scale: 1 and every MacBook, iPhone, and modern Android device produces a visibly soft export. I clamp it with Math.max(devicePixelRatio, 2) so even non-Retina users get a crisp minimum, without going overboard to 3x/4x on already-high-DPI devices (which tanks canvas generation speed for no visible gain).
URL.createObjectURL leaks are real. If a user generates five documents in one session (trying different templates, tweaking a typo), and you never call URL.revokeObjectURL, each blob stays pinned in memory for the life of the tab. On low-memory mobile devices this is enough to crash the tab during a long editing session. Always pair createObjectURL with a revokeObjectURL cleanup, ideally right after the download fires or on component unmount.
Mobile keyboards break your live preview. When a virtual keyboard opens on a phone, it doesn't resize the viewport the way you'd expect — it just covers half the screen. If your live-preview panel is positioned with 100vh assumptions, it gets shoved off-screen or squashed. Switching to 100dvh (dynamic viewport height) and deferring the preview re-render until the input blurs (rather than on every keystroke) fixed both the layout jank and a real performance problem: re-rasterizing a styled DOM tree on every keypress on a mid-range Android phone is not free.
Wrapping Up

The bigger theme here: a huge number of "utility" web apps — resume builders, invoice generators, biodata makers, certificate creators — don't actually need a database at all. They need a well-modeled client-side state shape and a solid export pipeline. Skipping the backend isn't a limitation; for PII-adjacent tools, it's arguably the more responsible default.

Curious what the community thinks: for tools that handle personal data but don't need to persist it across sessions, should "no backend" be the default assumption rather than the exception? Where's the line where you'd actually reach for a database?

I Replaced a $40/mo PDF API with 200 Lines of Web Worker Code — Here's the Offline Invoice Tool I Built

deepak_dev — Sun, 06 Sep 2026 15:39:18 +0000

The bill that started this

I was paying $40/month for a PDF generation API to power a tiny internal invoicing tool for a client project. Forty bucks a month to convert some JSON into a PDF. That's it. That's the whole service.

I finally sat down on a Saturday to see if I could kill that subscription. Three weekends later, not only did I kill it — the replacement is faster than the API ever was, because there's no network round-trip at all.

This post is the log of how it went, in the order I actually hit the problems, not the order that makes me look competent.

Attempt #1: jsPDF on the main thread (it worked, until it didn't)

First pass was the obvious one — jsPDF running directly in the click handler:

function generateInvoice(data) {
  const doc = new jsPDF();
  doc.text(data.clientName, 20, 20);
  data.lineItems.forEach((item, i) => {
    doc.text(`${item.description} — $${item.amount}`, 20, 40 + i * 10);
  });
  doc.save('invoice.pdf');
}

Fine for a 3-line invoice. Once I tested with a 40-line-item invoice (a real client sent me one to test against), the tab froze for almost two full seconds. Not crashed — frozen. Scroll didn't work, buttons didn't respond, and on a mid-range Android phone it was closer to five seconds.

The main thread doing synchronous PDF math while also being responsible for painting the UI is exactly the kind of thing that looks fine in a demo and falls apart the moment a real user pastes in real data.

Attempt #2: move it to a Web Worker

Web Workers get talked about like they're this exotic tool for WASM and video processing. They're also just... a really good fit for "expensive synchronous work that a user is waiting on." I'd never reached for one before this project, mostly out of habit.

The tricky part isn't the worker itself, it's that jsPDF assumes it has access to document and window in a couple of code paths (font metrics, mostly), which don't exist inside a worker. I ended up switching to pdfkit compiled for the browser, which is worker-friendly out of the box.

// pdf.worker.js
import PDFDocument from 'pdfkit/js/pdfkit.standalone.js';
import blobStream from 'blob-stream';

self.onmessage = (e) => {
  const { invoice } = e.data;
  const doc = new PDFDocument({ size: 'A4', margin: 50 });
  const stream = doc.pipe(blobStream());

  doc.fontSize(20).text(invoice.clientName, { align: 'left' });
  doc.moveDown();

  invoice.lineItems.forEach(item => {
    doc.fontSize(11).text(`${item.description}`, { continued: true });
    doc.text(`$${item.amount.toFixed(2)}`, { align: 'right' });
  });

  doc.fontSize(14).text(`Total: $${invoice.total.toFixed(2)}`, { align: 'right' });
  doc.end();

  stream.on('finish', () => {
    const blob = stream.toBlob('application/pdf');
    self.postMessage({ status: 'done', blob });
  });
};

// main thread
const worker = new Worker(new URL('./pdf.worker.js', import.meta.url));

function generateInvoice(invoice) {
  return new Promise((resolve) => {
    worker.postMessage({ invoice });
    worker.onmessage = (e) => {
      if (e.data.status === 'done') resolve(e.data.blob);
    };
  });
}

Same 40-line invoice, same laptop: zero dropped frames. The UI stays fully interactive the entire time because the worker is a genuinely separate thread — it's not just async, it's parallel.

Thing I got wrong the first time: I forgot workers can't be spun up from a file:// context or without a proper module bundler setup, and I burned about 40 minutes assuming my code was broken when it was actually a Vite config issue with worker module resolution. If you hit a silent worker failure with nothing in the console, check your bundler's worker plugin config before you check your logic.

The offline problem nobody asked for (but I wanted anyway)

Once the PDF generation was fully client-side, I realized the whole app could work with no network at all — except drafts were still sitting in a useState/Svelte store that vanished on refresh.

IndexedDB is the obvious answer here, but the raw API is genuinely unpleasant to write by hand. I used idb (a tiny promise wrapper) instead of hand-rolling transaction callbacks:

import { openDB } from 'idb';

const dbPromise = openDB('invoices-db', 1, {
  upgrade(db) {
    db.createObjectStore('drafts', { keyPath: 'id' });
  },
});

export async function saveDraft(invoice) {
  const db = await dbPromise;
  await db.put('drafts', invoice);
}

export async function getAllDrafts() {
  const db = await dbPromise;
  return db.getAll('drafts');
}

Paired with a service worker caching the app shell, the tool now works on a plane with no wifi, which was never a requirement — I just liked the idea that an invoicing tool shouldn't care whether your internet is working. Freelancers filling these out from a job site with bad signal was the actual use case that made this worth doing, once I thought about it.

Things that bit me that I didn't expect

Font embedding bloats the bundle fast. Embedding a single custom font (for brand consistency on the invoice) added close to 300KB to the worker bundle. I switched to subsetting the font to only the character set actually used (fontkit + a subsetting step at build time) and got that down under 40KB.
blob-stream output isn't a real Blob until finish fires. I tried reading the blob immediately after doc.end() more than once before realizing the stream is asynchronous even though nothing about the API signals that clearly.
Safari's IndexedDB implementation in private browsing mode silently caps storage at a tiny quota. Drafts would save fine in a normal tab and then quietly fail in private mode with no error thrown. I added a try/catch around every saveDraft call and a visible "couldn't save — are you in private browsing?" banner as a fallback, since there's no reliable way to detect private mode ahead of time anymore.
Where it landed
PDF generation: ~180ms for a 40-line invoice, entirely off the main thread.
Works fully offline after first load.
Zero backend, zero monthly PDF API bill.
Total JS shipped to the client (worker included): ~85KB gzipped.

What I'd tell someone starting this today

If your app does any synchronous, CPU-heavy work in response to a user action — PDF generation, image processing, large JSON parsing, CSV crunching — try the Web Worker before you reach for a paid API or a backend endpoint. It's not as scary as it sounds, and libraries meant for Node (like pdfkit) often work in a worker context even when they choke on window-dependent assumptions in the main thread.

The offline piece was the bonus I didn't plan for, and it turned out to be the feature actual users mentioned first when I asked for feedback. Sometimes the thing you build because it's technically interesting is the thing that ends up mattering to the person using it.

Happy to share the full repo structure or the Vite worker config in the comments if it'd help — that config took longer to get right than everything else in this post combined.