DEV Community: Rohith Gilla

Generating Realistic Seed Data That Respects Foreign Keys, in 20 Seconds

Rohith Gilla — Wed, 22 Apr 2026 11:17:13 +0000

Someone asks for a demo. You need 10,000 users, 30,000 orders, a handful of
products, and enough variety that the UI does not look fake. You have
twenty minutes.

If you have been here before, you know the options:

Write a seed script. Open your editor, import Faker, write the loops, get the foreign keys wrong twice, rerun, get them right, run into a FOREIGN KEY constraint violation on line 847, swear.
Use a CLI tool. Install something, read its YAML schema format, configure it, discover that it does not handle your vendor-specific column type, give up.
Copy a SQL file from Stack Overflow. Hope it does not have DROP DATABASE in it somewhere.

I went through option 1 enough times that I built option 4 into data-peek:
a Data Generator tab that reads your table's schema, guesses how each
column should be filled, samples existing foreign key values from the real
database, and batch-inserts. No configuration required for the common case.

What it does from the outside

Open a table. Click "Generate Data." A new tab opens with a row per
column. Each column is pre-filled with a sensible generator based on its
name and type:

email → faker.internet.email
first_name → faker.person.firstName
created_at → faker.date.recent
uuid, guid → faker.string.uuid
user_id with a foreign key → fk-reference to users.id
A status enum column → random-enum with the discovered values
Anything unrecognized → lorem.word (clearly useless, easy to spot and replace)

You can override any of these, add a null percentage (for "15% of rows
should have NULL in this column"), set a seed for reproducibility, and
preview the first five rows before committing. Then you set the row count
and hit Generate.

The heuristic table

The whole "it just works" impression comes from one lookup table in
src/main/data-generator.ts:

const HEURISTICS: Heuristic[] = [
  { pattern: /^email$/i,                    generator: { generatorType: 'faker', fakerMethod: 'internet.email' } },
  { pattern: /^(first_?name|fname)$/i,      generator: { generatorType: 'faker', fakerMethod: 'person.firstName' } },
  { pattern: /^(last_?name|lname|surname)$/i, generator: { generatorType: 'faker', fakerMethod: 'person.lastName' } },
  { pattern: /^(name|full_?name)$/i,        generator: { generatorType: 'faker', fakerMethod: 'person.fullName' } },
  { pattern: /^(phone|mobile|cell)$/i,      generator: { generatorType: 'faker', fakerMethod: 'phone.number' } },
  { pattern: /^(city)$/i,                   generator: { generatorType: 'faker', fakerMethod: 'location.city' } },
  { pattern: /^(country)$/i,                generator: { generatorType: 'faker', fakerMethod: 'location.country' } },
  { pattern: /^(url|website)$/i,            generator: { generatorType: 'faker', fakerMethod: 'internet.url' } },
  { pattern: /^(bio|description|about)$/i,  generator: { generatorType: 'faker', fakerMethod: 'lorem.paragraph' } },
  { pattern: /^(title|subject)$/i,          generator: { generatorType: 'faker', fakerMethod: 'lorem.sentence' } },
  { pattern: /^(company|organization)$/i,   generator: { generatorType: 'faker', fakerMethod: 'company.name' } },
  { pattern: /^(created|updated|deleted)_?(at|on|date)?$/i,
                                            generator: { generatorType: 'faker', fakerMethod: 'date.recent' } },
  { pattern: /^(uuid|guid)$/i,              generator: { generatorType: 'uuid' } }
]

This is boring and I am proud of it. Every single entry was added the
first time I opened a new table and saw a generator make a wrong guess.
"Oh, it filled bio with lorem.word, that should be lorem.paragraph" —
and then I added the rule. The heuristic is 40 lines and handles the
column names I have seen on every CRUD schema I have built in the last
decade.

Anything not in the table falls through a data-type-based fallback
(integers get random-int, booleans get random-boolean, dates get
random-date), and everything else defaults to faker.lorem.word — a
deliberate "this is clearly wrong, go fix it" placeholder.

The FK sampler

This is the part that turns it from a toy into something you would
actually use.

When you mark a column as fk-reference, you point it at the parent table
and column. Before any rows are generated, the main process samples up to
1000 real values from that referenced column:

export async function resolveFK(
  adapter, connectionConfig, schema, fkTable, fkColumn
): Promise<unknown[]> {
  const dbType = connectionConfig.dbType
  const quotedTable = quoteId(fkTable, dbType)
  const tableRef =
    schema && schema !== 'public' && schema !== 'main' && schema !== 'dbo'
      ? `${quoteId(schema, dbType)}.${quotedTable}`
      : quotedTable
  const sql =
    dbType === 'mssql'
      ? `SELECT TOP 1000 ${quoteId(fkColumn, dbType)} FROM ${tableRef}`
      : `SELECT ${quoteId(fkColumn, dbType)} FROM ${tableRef} LIMIT 1000`

  try {
    const result = await adapter.query(connectionConfig, sql)
    return result.rows.map((row) => {
      const r = row as Record<string, unknown>
      return r[fkColumn]
    })
  } catch {
    return []
  }
}

Then row generation just picks randomly from that sampled pool:

case 'fk-reference': {
  const fkKey = `${col.fkTable}.${col.fkColumn}`
  const ids = fkData.get(fkKey) ?? []
  if (ids.length === 0) return null
  return ids[Math.floor(Math.random() * ids.length)]
}

Two design calls worth defending.

It samples 1000, not all. On a 5-million-row users table, reading
every ID to pick from takes minutes. Sampling a thousand gives you enough
variety that your 10,000 generated orders rows will reference a
reasonable spread of users without being a perfect distribution. Perfect
distributions are for statisticians; believable demos are for everyone
else.

It returns an empty array on error, silently. If the parent table
does not exist, or the column has been renamed, or you do not have
SELECT on it, we fall back to NULL in the generated column. I go back and
forth on whether this should be a hard error instead. In practice it is
the right default for demos — you can still generate the rest of the
columns and fix the FK column after — but I plan to add a visible warning
indicator for it.

The generator is one table at a time, not the whole database. A "seed
the whole DB in dependency order" mode would require a topological sort
of the foreign-key graph, and the right UX for it is not obvious. Right
now the workflow is: generate the parent tables first (users, products),
then the child tables (orders, line_items) with FK-references pointing
back. It is an extra step but it keeps the mental model tiny.

Guarding against prototype pollution

Here is a thing I did not expect to care about when I started. The
fakerMethod string looks like internet.email and I call it
dynamically:

function callFakerMethod(method: string): unknown {
  const parts = method.split('.')
  if (parts.length !== 2) return faker.lorem.word()

  const [ns, fn] = parts
  if (ns === '__proto__' || ns === 'constructor' || ns === 'prototype') return faker.lorem.word()
  if (fn === '__proto__' || fn === 'constructor' || fn === 'prototype') return faker.lorem.word()

  const fakerAny = faker as unknown as Record<string, unknown>
  const namespace = fakerAny[ns]
  if (!namespace || typeof namespace !== 'object') return faker.lorem.word()

  const func = (namespace as Record<string, unknown>)[fn]
  if (typeof func !== 'function') return faker.lorem.word()

  const result = (func as () => unknown).call(namespace)
  // ...
}

The __proto__ / constructor / prototype checks are there because the
fakerMethod value comes from the renderer, which means it ultimately
comes from user input in the generator UI. Without the guards, someone
could enter __proto__.valueOf as their method name and get, at best, a
crash and, at worst, prototype pollution across the whole main process.
Is it exploitable in a single-user desktop app? Probably not. Did I add
it anyway? Yes — because the code looked dangerous in review and "probably
not exploitable" is not a principle I want the codebase to live by.

Batching and cancellation

Ten thousand rows is nothing. A hundred thousand starts to hurt. The
batch inserter (src/main/batch-insert.ts) chunks the rows into
batches the user configures, sends progress back over IPC after each
batch, and honors a cancel flag:

ipcMain.handle('db:generate-cancel', async () => {
  cancelDataGen = true
  requestCancelBatchInsert()
  return { success: true }
})

The progress callback (sendProgress) updates a progress bar in the
renderer between batches. "Cancel" sets the flag, the current batch
finishes, and then the loop bails out before starting the next one.
Nothing magical, but it means you can start a 500,000-row generation,
realize you picked the wrong column mapping, and stop without waiting.

Preview mode

Before committing, the same pipeline runs with rowCount: 5 and returns
the preview rows instead of inserting:

const previewConfig = { ...genConfig, rowCount: 5 }
const rows = generateRows(previewConfig, fkData)
return { success: true, data: { rows } }

This alone has saved me from maybe twenty bad seed runs. "Oh, the email
column is getting lorem.word because I forgot to override it" — caught in
the preview, fixed, re-previewed, then committed.

What I'd do differently

A topological-sort mode for seeding a whole schema. The current
table-at-a-time model is fine for small datasets; for end-to-end test
fixtures it is annoying. A mode that takes a schema, orders the tables
by FK dependency, and seeds them all with sensible defaults is the
obvious next step.

Better heuristic for numeric foreign keys. If a column is named
owner_id and there is no declared FK but there is a users.id column
in the same schema, we could offer a suggestion. Right now we only use
declared foreign keys, so schemas without formal FK constraints (hello,
legacy MySQL) miss out.

Locales. Faker supports locales; data-peek just uses the default.
Generating data for a Japanese demo app and getting all-American
addresses is a dead giveaway. Adding a locale picker is a small change I
keep forgetting to do.

Try it

Open a table in data-peek, click Generate Data, hit Preview, then
Generate. The whole thing is at datapeek.dev.
The generator code is in src/main/data-generator.ts and
src/main/batch-insert.ts, and the UI is
src/renderer/src/components/data-generator.tsx. MIT source, free for
personal use.

The pitch: the next time someone asks you for a demo dataset in twenty
minutes, you do not have to open a fresh seed.ts file.

Stop Pasting \timing — Run Your SQL 100 Times and Get p99

Rohith Gilla — Wed, 15 Apr 2026 04:21:49 +0000

Here is a trap I have fallen into more times than I can count.

I write a query. I run it. It takes 48ms. I nod, satisfied, and deploy it.
In production it p99s at 1.8 seconds during peak traffic, the on-call
engineer pages me, and I spend the next hour explaining how "on my machine
it was fine."

A single EXPLAIN ANALYZE run is not a benchmark. It is an anecdote. The
first run pays the cost of cold caches, parse, plan, and whatever else the
database had queued. The second run is suspiciously fast because everything
is now in the buffer cache. Somewhere between "ran it once in psql" and
"ran it under real load" lives the actual distribution of latencies — and
that distribution is what matters.

The traditional fix is an ad-hoc bash loop:

for i in {1..100}; do
  psql -c "\timing" -c "SELECT ... your query ..." \
    | grep 'Time:'
done | awk '{print $2}' | sort -n | ...

And then you remember you do not know the awk incantation for p99 off the
top of your head, you open Stack Overflow, you copy something, it gives you
the wrong percentile, you mutter, and you give up.

data-peek has a Benchmark button. Click it, pick how many runs, wait, read
the percentiles. That is the whole interaction.

What you get

The button (src/renderer/src/components/benchmark-button.tsx) is a dropdown
with four presets:

const RUN_OPTIONS = [
  { count: 10,  label: '10 runs',  description: 'Quick test' },
  { count: 50,  label: '50 runs',  description: 'Standard benchmark' },
  { count: 100, label: '100 runs', description: 'Detailed analysis' },
  { count: 500, label: '500 runs', description: 'Statistical precision' }
]

Pick one, the currently open query runs that many times, and the results
panel updates with:

Average, min, max latency
p90, p95, p99 latency
Standard deviation (the shape of the distribution matters; a query with 40ms average and 200ms std dev is a different beast than one with 40ms average and 2ms std dev)
Per-phase breakdown — connect, plan, execute, fetch — each with its own percentiles

That last one is the difference between "the query is slow" and "the query
is fast but the planner is slow." I would not have guessed how often the
answer is the second one until I could actually see it.

How the runs happen

The renderer calls db:benchmark over IPC with a run count, and the main
process loops through the query that many times, collecting telemetry on
each pass. The important bits from src/main/ipc/query-handlers.ts:

ipcMain.handle(
  'db:benchmark',
  async (_, { config, query, runCount }) => {
    // Validate run count
    if (runCount < 1 || runCount > 1000) {
      return { success: false, error: 'Run count must be between 1 and 1000' }
    }

    const adapter = getAdapter(config)
    const telemetryRuns: QueryTelemetry[] = []

    for (let i = 0; i < runCount; i++) {
      const executionId = `benchmark-${Date.now()}-${i}`

      try {
        const result = await adapter.queryMultiple(config, query, {
          executionId,
          collectTelemetry: true
        })

        if (result.telemetry) {
          telemetryRuns.push(result.telemetry)
        }

        // Small delay between runs to avoid overwhelming the database
        if (i < runCount - 1) {
          await new Promise((resolve) => setTimeout(resolve, 10))
        }
      } catch (runError) {
        // If a run fails, log it but continue
        log.warn(`Benchmark run ${i + 1} failed:`, runError)
      }
    }

    if (telemetryRuns.length === 0) {
      return { success: false, error: 'All benchmark runs failed' }
    }

    const benchmarkResult = telemetryCollector.aggregateBenchmark(telemetryRuns)
    return { success: true, data: benchmarkResult }
  }
)

Three things I want to point out.

Failed runs do not abort the benchmark. If run 37 out of 100 hits a
deadlock and errors, we log it and keep going. At the end, as long as at
least one run succeeded, we aggregate. This matters because in a real
database, transient failures happen, and throwing away 99 successful runs
because one hit a lock is worse than reporting on 99 successes.

There is a 10ms delay between runs. I went back and forth on this.
Without it, 500 runs slam the server and you get a warped picture — the
later runs start queuing because the server is busy serving the earlier
runs. With it, you give the database a breath between iterations and the
distribution starts to look like what you would see under spaced-out
production traffic. 10ms is a compromise; the correct answer depends on
your workload.

collectTelemetry: true is the hook into the per-phase breakdown. The
adapter instruments connect/plan/execute/fetch and returns a
QueryTelemetry per run, which is how we end up with phase-level
percentiles instead of just end-to-end numbers.

The percentile math

The percentile function is deliberately unfancy. It lives in
packages/shared/src/index.ts so both main and renderer can use the same
implementation:

export function calcPercentile(sorted: number[], p: number): number {
  if (sorted.length === 0) return 0
  if (sorted.length === 1) return sorted[0]
  const idx = Math.ceil((p / 100) * sorted.length) - 1
  return sorted[Math.max(0, Math.min(idx, sorted.length - 1))]
}

This is the "nearest-rank" percentile, the definition you learn in stats 101.
It is not the interpolated version you get from numpy by default, and it is
not the version the Postgres docs use internally. It is the version that
matches how most developers intuit percentiles: "p99 is a real value from
the dataset, not an interpolated one between two samples." With 500 runs,
the difference between nearest-rank and interpolated is in the noise.

The aggregation:

aggregateBenchmark(runs: QueryTelemetry[]): BenchmarkResult {
  const durations = runs
    .map((r) => r.totalDurationMs)
    .sort((a, b) => a - b)
  const sum = durations.reduce((a, b) => a + b, 0)
  const avg = sum / durations.length

  const stats = {
    avg,
    min: durations[0],
    max: durations[durations.length - 1],
    p90: calcPercentile(durations, 90),
    p95: calcPercentile(durations, 95),
    p99: calcPercentile(durations, 99),
    stdDev: calcStdDev(durations, avg)
  }
  // ... then the same treatment for each phase
}

Sort once, pull percentiles by index, done. The stddev lives in shared
too and is the textbook sqrt(mean((x - mean)^2)). No external stats
library; I refuse to pull in simple-statistics or d3-array for 30 lines
of arithmetic.

What the per-phase breakdown taught me

Running benchmarks on my own queries, I learned three things that surprised
me.

Connect time is not zero. Even with pooling in a desktop client, the
first few runs of a benchmark pay a noticeable reconnect cost. By run 10 it
has settled. If your app creates a fresh connection on every query (hi,
serverless), your production p99 is going to be dominated by that
connection step and no amount of index-tuning will save you.

Plan time varies more than execute time for small, simple queries. If
your query executes in 2ms but the planner takes 1–4ms of variable time,
your query is effectively plan-bound. Prepared statements stop being
"nice to have" and become the actual fix.

Fetch is where network latency hides. If you are running data-peek on
your laptop against a remote Postgres, the fetch phase is where the
round-trip tax shows up. Running the same benchmark on the same server
against the same database will show you an entirely different fetch
percentile. That is the real cost of remote development.

What I'd do differently

I'd add a "warmup" option. Right now the first few runs are always
slower than the rest because caches are cold. I report them as part of the
distribution, which is honest but not always useful. A "discard first N"
flag would make it easy to ask "what does the steady-state p99 look like?"
without manually trimming the data.

I'd add a run histogram. p50/p90/p99 are summaries. A 20-bucket
histogram would show you the shape directly — bimodal distributions
(which almost always mean "cache hit vs cache miss") become obvious
instantly. The BenchmarkResult has the raw durations, so this is a
render-side change, not a data change.

I'd let you compare two benchmarks. "Did my new index help?" is the
question. Right now you screenshot the before, run the benchmark again
after, and eyeball the difference. A stored-comparison view would be the
feature that actually ships index changes with confidence.

Try it

Write a query. Click the Benchmark button. Pick 100 runs. Look at the
distribution, not the average. That is the one-sentence pitch.

data-peek lives at datapeek.dev. The benchmark
path is src/main/ipc/query-handlers.ts (db:benchmark) and
src/main/telemetry-collector.ts (aggregateBenchmark) if you want to
read how it is wired. MIT source, free for personal use.

Debugging Postgres LISTEN/NOTIFY Is Finally Pleasant

Rohith Gilla — Tue, 14 Apr 2026 04:38:23 +0000

I have written the same 40-line Node script to debug a Postgres LISTEN
channel at least six times. You know the one:

const { Client } = require('pg')
const c = new Client({ connectionString: process.env.DB })
await c.connect()
await c.query('LISTEN order_events')
c.on('notification', (m) => console.log(new Date(), m.channel, m.payload))
console.log('listening...')

Save it as listen.js, node listen.js, stare at the terminal, trigger the
thing you are debugging, and pray the connection does not drop before the
event arrives — because if it does, you scroll back up, Ctrl+C, re-run, and
now the event has already happened and nobody is listening.

I rewrote this script on at least four different laptops. On two of them, I
rewrote it twice because I forgot where I put it. At some point you have to
stop.

The Postgres LISTEN/NOTIFY panel in data-peek is the version I wish I had had
the first time.

What it does

Subscribe to one or many channels on a connection with a single input.
See every event that arrives, live, with timestamp, channel, and payload.
Keep the last 10,000 events per connection in a local SQLite database, so if you walk away and come back an hour later, the history is still there.
Survive a dropped connection. If the Postgres server restarts, or your laptop's WiFi blips, the listener reconnects with exponential backoff and re-subscribes to everything you had open.
NOTIFY back with a "Send" button, so you can smoke-test your own channel without leaving the app.

The whole thing is one pg.Client per connection held open in the Electron
main process. The renderer just sends subscribe/unsubscribe IPC messages and
receives events through a webContents channel.

The reconnect loop

If you have written a long-lived pg listener before, you know the three
things that go wrong: the client drops, the tunnel dies, or your backoff is
too aggressive and you hammer a recovering server. Here is the relevant slice
from src/main/pg-notification-listener.ts:

const MAX_BACKOFF_MS = 30_000
const MAX_EVENTS_PER_CONNECTION = 10000

function scheduleReconnect(connectionId, config, channels, backoffMs) {
  const entry = listeners.get(connectionId)
  if (entry?.destroyed) return

  const nextBackoff = Math.min(backoffMs * 2, MAX_BACKOFF_MS)

  const timer = setTimeout(() => {
    const current = listeners.get(connectionId)
    if (current?.destroyed) return
    connectListener(connectionId, config, channels, nextBackoff)
  }, backoffMs)

  if (entry) entry.reconnectTimer = timer
}

The base delay is 1000ms, we double on every failure, and we cap at 30
seconds. That cap matters more than you think — without it, after enough
failures you end up with a listener that tries once an hour and you swear
the panel "doesn't work anymore" when actually it just happens to be in
a two-hour retry gap.

The destroyed flag is the quiet hero. Every ListenerEntry has one:

interface ListenerEntry {
  client: Client
  tunnelSession: TunnelSession | null
  channels: Set<string>
  connectedSince: number
  reconnectTimer?: ReturnType<typeof setTimeout>
  destroyed: boolean
}

When the user closes the panel or switches connections, I set destroyed = true before calling client.end(). That matters because client.end()
triggers the 'end' event, which would otherwise kick off a reconnect
attempt three seconds later — a stubborn zombie listener that refuses to die.
The check if (entry.destroyed) return at the top of the reconnect branch
is what makes the cleanup actually clean up.

Both the 'error' and 'end' handlers route through the same reconnect
path:

client.on('error', (err) => {
  if (entry.destroyed) return
  log.error(`pg notification client error for ${connectionId}:`, err)
  scheduleReconnect(connectionId, config, entry.channels, backoffMs)
})

client.on('end', () => {
  if (entry.destroyed) return
  log.warn(`pg notification client disconnected for ${connectionId}, reconnecting...`)
  scheduleReconnect(connectionId, config, entry.channels, backoffMs)
})

Note that I re-subscribe to entry.channels, not to the original channels
parameter. If the user added a channel since the initial connect, this makes
sure the reconnect picks up the new set. I did not have this right the first
time; I lost a channel on every reconnect until I noticed.

Event history, in SQLite

Events are not just forwarded to the renderer — they also go into a local
SQLite database in the user's Electron data dir:

sqliteDb.exec(`
  CREATE TABLE IF NOT EXISTS pg_notification_events (
    id TEXT PRIMARY KEY,
    connection_id TEXT NOT NULL,
    channel TEXT NOT NULL,
    payload TEXT NOT NULL,
    received_at INTEGER NOT NULL
  )
`)

sqliteDb.exec(`
  CREATE INDEX IF NOT EXISTS idx_pne_connection_received
  ON pg_notification_events (connection_id, received_at DESC)
`)

Three reasons this matters:

Close the panel, come back later. Your events are still there. This alone is worth the whole feature — I used to screenshot my terminal before closing the throwaway script.
The ring-buffer cap is enforced in SQL, not in JS. On every insert I count the rows for that connection and DELETE the oldest if we exceed 10,000. That keeps the JS side completely stateless.
It survives app restarts. A SQLite file in app.getPath('userData') is the simplest possible durable store.

The trim query is worth sharing because it is the one where I almost used a
LIMIT on a DELETE (which SQLite supports but is a footgun):

if (count > MAX_EVENTS_PER_CONNECTION) {
  const excess = count - MAX_EVENTS_PER_CONNECTION
  db.prepare(`
    DELETE FROM pg_notification_events
    WHERE id IN (
      SELECT id FROM pg_notification_events
      WHERE connection_id = ?
      ORDER BY received_at ASC
      LIMIT ?
    )
  `).run(event.connectionId, excess)
}

The subquery guarantees we delete the oldest excess rows for this
connection, not the oldest rows overall. On a laptop with two databases
open, the global ordering would let one chatty channel evict events from
the quiet one.

Identifier quoting for channel names

This one is easy to miss. LISTEN takes an identifier, not a string literal,
so you cannot parameterize it with a $1 placeholder. You have to interpolate
— carefully:

function quoteIdent(name: string): string {
  return `"${name.replace(/"/g, '""')}"`
}

await client.query(`LISTEN ${quoteIdent(channel)}`)

Postgres identifier quoting uses "" to escape a literal double-quote inside
a quoted identifier. If your channel name is "foo"bar", that becomes
"""foo""bar""" after quoting, which Postgres parses back to "foo"bar".
It is ugly but it is the only correct way. A channel named order; DROP TABLE users; would otherwise be a live SQL injection.

What I'd do differently

The per-connection ring buffer should be per-channel. Right now one
chatty channel on a shared connection can push a quiet channel's history out
the back of the buffer. Partitioning the cap by (connection_id, channel)
would fix it. I did not because it would complicate the trim query and
nobody has hit the limit in practice yet.

I should persist subscriptions across app restarts. Today, if you close
data-peek and re-open it, your subscribed channels are gone. The SQLite DB
has the events but not the subscriptions. A small pg_subscriptions
table keyed by connection_id would let the app restore on startup. It is
on the list.

Reconnect should jitter. 1s, 2s, 4s, 8s is a textbook exponential
backoff, but if two clients lose their connection at the same instant they
reconnect in lockstep. Adding a random 0–500ms jitter would be three lines
and would be the right thing to do.

If you want to try it

It lives in src/main/pg-notification-listener.ts if you want to read the
full 300 lines. The panel UI is src/renderer/src/components/pg-notifications-panel.tsx.

data-peek is at datapeek.dev. Free for personal
use, MIT source. If you have ever rewritten the listen.js script, you will
know exactly why this exists.

I Can Finally Screen-Share My SQL Client Without Leaking Prod Data

Rohith Gilla — Mon, 13 Apr 2026 04:10:33 +0000

We were halfway through a customer demo when I remembered I was connected to
staging, not to the demo seed database. I had just typed
SELECT * FROM users LIMIT 20 and hit Cmd+Enter. Twenty real email addresses
appeared on my screen, which was mirrored to a conference room of people who
were not supposed to see them.

I alt-tabbed to my Zoom window so fast I think I pulled a tendon.

There was no harm done — staging data is obfuscated, the emails were fake,
the customer is still a customer. But the adrenaline was real, and the sheer
avoidable stupidity of the situation stuck with me. Every SQL client I have
ever used will happily render hunter2 in plaintext to whoever is pointing a
camera at your laptop. That is not a sensible default in 2026.

So I added a data masking layer to data-peek.

What it does

Two things, really.

It auto-masks columns by name. Out of the box, every column whose name
matches email, password, passwd, pwd, ssn, social_security,
token, secret, api_key, or apikey is blurred. Phone and address
patterns are in the rule list but disabled by default because they create too
many false positives on arbitrary schemas. The rules are just regexes, so
you can add your own (for my team: a stripe_ rule that catches
stripe_customer_id and friends).

You can manually mask any column, any time. Click a column header, hit
"Mask Column," done. The masked state is scoped per tab, so masking
users.full_name in one query does not affect a different query.

Masked cells render with filter: blur(5px) and user-select: none. You can
see the shape of the data — same row height, same column width, no layout
shift — but not the contents. When you actually need to see a value, hold
Alt and hover. The cell reveals for as long as you hold it and re-blurs
when you let go.

That hover-to-peek mode is the best part. It keeps you in the flow:
"checking a single email address to verify an account" no longer means
revealing twenty of them.

The rules

These are the defaults, straight from src/renderer/src/stores/masking-store.ts:

const DEFAULT_RULES: AutoMaskRule[] = [
  { id: 'email',    pattern: 'email',                                 enabled: true  },
  { id: 'password', pattern: 'password|passwd|pwd',                   enabled: true  },
  { id: 'ssn',      pattern: 'ssn|social_security',                   enabled: true  },
  { id: 'token',    pattern: 'token|secret|api_key|apikey',           enabled: true  },
  { id: 'phone',    pattern: 'phone|mobile|cell',                     enabled: false },
  { id: 'address',  pattern: 'address|street',                        enabled: false }
]

Two things I learned writing the matcher.

First, case insensitivity is mandatory, not optional. Different ORMs and
naming conventions will give you email, Email, EMAIL, emailAddress,
email_addr. The matcher compiles each pattern as new RegExp(rule.pattern, 'i')
so one rule catches them all. Without that flag, Email slips through
every time and you have a false sense of security.

Second, the effective mask is the union of manual and auto. If you
manually unmask a column but the auto-rule still matches, the auto-rule wins
on the next render. This was a deliberate choice: the whole point is to fail
closed. If you want to permanently exclude a column, you edit the rule,
not the cell.

Here is the resolver that combines both sources:

getEffectiveMaskedColumns: (tabId, allColumns) => {
  const { maskedColumns, autoMaskRules, autoMaskEnabled } = get()
  const manualMasked = new Set(maskedColumns[tabId] ?? [])

  if (!autoMaskEnabled) return manualMasked

  const effective = new Set(manualMasked)
  for (const col of allColumns) {
    for (const rule of autoMaskRules) {
      if (!rule.enabled) continue
      try {
        const regex = new RegExp(rule.pattern, 'i')
        if (regex.test(col)) {
          effective.add(col)
          break
        }
      } catch {
        // Invalid regex — skip
      }
    }
  }
  return effective
}

The try/catch around the regex is there because the rule list is
user-editable. If someone adds user[ as a pattern, I do not want the entire
results grid to crash. The invalid rule silently no-ops. A production-grade
version would surface a red squiggle in the rule editor; I did not do that
yet.

The render path

The masking logic lives in Zustand; the render logic lives in one small
cell component. The meaningful lines from data-table.tsx:

function MaskedCell({ isMasked, hoverToPeek, children }: MaskedCellProps) {
  const [peeking, setPeeking] = useState(false)

  const onMouseEnter = (e: React.MouseEvent) => {
    if (hoverToPeek && e.altKey) setPeeking(true)
  }

  return (
    <span
      onMouseEnter={onMouseEnter}
      onMouseLeave={() => setPeeking(false)}
      style={peeking ? undefined : { filter: 'blur(5px)', userSelect: 'none' }}
    >
      {children}
    </span>
  )
}

That is the whole thing. No canvas trickery, no data-URL sleight of hand,
no modified result set — the raw value is still in the DOM. If someone is
smart enough to open devtools on your SQL client during a demo, they can dig
it out. The threat model here is "accidentally revealing data to a camera or
screen-share," not "malicious insider with inspector access." I think that is
the right level to aim at. Perfect is the enemy of I will actually use it
every day.

The userSelect: 'none' matters more than the blur: it means you cannot
double-click and copy a masked value into the clipboard by reflex. One of
the quiet ways PII leaks is not from someone reading your screen, it is from
you pasting a blurred value into Slack thinking "surely the blur meant that
wasn't the real thing."

What I'd do differently

I wish I had done it the other way around. The blur is a presentation
trick. A truly paranoid version would mask at the IPC boundary — have the
main process redact values before they ever hit the renderer, based on the
same rules. That way a devtools inspector genuinely cannot see the original.
The tradeoff is that hover-to-peek becomes a round-trip through IPC, which
adds latency to the interaction. I chose the fast UX and a weaker threat
model. I still think it is the right call, but I want the IPC-redaction
option as a toggle for security-conscious users.

The rules should be repo-shareable. Right now each user's rules live in
their own Zustand-persisted local storage. But a team would reasonably want
a shared rule set — "our customers table has a pci_encrypted_pan column,
mask that everywhere" — and right now there is no way to distribute that
short of everyone copy-pasting it manually. A .data-peek-masks.json at the
repo root would solve it. Queued up.

The phone pattern should probably be on by default. It is off because
mobile_application_id and friends match the pattern and create noise. But
"noise from too much masking" is a strictly better failure mode than
"leaking a phone number in a Loom." I will flip the default.

The honest pitch

If you have ever had a "I was sharing my screen" moment, this feature is for
you. If you record Loom demos, pair on production bugs, or stream your
coding, this feature is definitely for you.

data-peek is at datapeek.dev. The masking code is
open source — src/renderer/src/stores/masking-store.ts if you want to
read it or port the idea to your own tool. Copy it, improve it, tell me what
you did differently. The goal is fewer adrenaline spikes in conference rooms.

I Put pg_stat_activity in My SQL Client — And Added a Kill Button

Rohith Gilla — Sat, 11 Apr 2026 06:25:11 +0000

It was 11:47 PM when the Datadog alert came in. API latency on /checkout had
tripled. I SSH'd into the bastion, opened psql, and started typing the query
I have typed a thousand times:

SELECT pid, state, EXTRACT(EPOCH FROM (now() - query_start)) AS seconds, query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY query_start;

Then I ran it. Then I ran it again six seconds later. Then again. Then I
opened a second tab and started typing SELECT * FROM pg_locks because I was
pretty sure one of the long-running queries was blocking something. Three
terminals, two SSH sessions, one increasingly tired human.

Every Postgres operator has been here. The data you need lives in system
views — pg_stat_activity, pg_locks, pg_statio_user_tables,
pg_stat_user_tables. Reaching for them through a shell at midnight is a
productivity tax I got tired of paying.

So I built the Connection Health Monitor into data-peek.

What it does

The Health Monitor is a dedicated tab — not a modal, not a sidebar — that
refreshes every 2, 5, 10, or 30 seconds (configurable), and shows four panels:

Active Queries — everything in pg_stat_activity that isn't idle, with duration, wait events, and a kill button next to each row.
Table Sizes — the top 50 tables by total size, including heap and index bytes, with a row-count estimate from pg_stat_user_tables.n_live_tup.
Cache Hit Ratios — buffer and index cache hit percentages, plus a per-table breakdown of seq-scan vs index-scan counts.
Locks & Blocking — the classic blocked/blocking join from pg_locks, with both the blocked query and the query holding the lock visible side by side.

The kill button calls pg_cancel_backend(pid). No confirmation dialog. If
you hit it by accident, the worst that happens is a query fails and you run
it again. That is the right tradeoff at midnight.

Every panel has a "Share" button that generates a clean screenshot suitable
for pasting into an incident Slack channel. That last bit came from a real
incident where I wanted to show the on-call DBA what I was seeing and ended
up cropping and masking a terminal screenshot for ten minutes. Now it is a
single click.

How it's wired

The Health Monitor is an honest, boring pipeline, and I think that is the
point.

┌────────────────────────────┐
│  HealthMonitor.tsx (React) │  ← refresh interval, kill buttons, share UI
└──────────────┬─────────────┘
               │ window.api.db.*
┌──────────────┴─────────────┐
│  health-handlers.ts (IPC)  │  ← ipcMain.handle('db:active-queries', …)
└──────────────┬─────────────┘
               │ getAdapter(config)
┌──────────────┴─────────────┐
│  postgres-adapter.ts       │  ← the actual SQL against pg_stat_*
└────────────────────────────┘

The IPC handlers (src/main/ipc/health-handlers.ts) are wafer-thin — each
one is about ten lines, dispatches to the adapter, and wraps the result in
the project's standard IpcResponse<T> shape:

ipcMain.handle('db:active-queries', async (_, config: ConnectionConfig) => {
  try {
    const adapter = getAdapter(config)
    const queries = await adapter.getActiveQueries(config)
    return { success: true, data: queries } as IpcResponse<typeof queries>
  } catch (error) {
    log.error('Failed to get active queries:', error)
    return { success: false, error: String(error) } as IpcResponse<never>
  }
})

That pattern ensures every health panel can fail independently. If pg_locks
is slow because something dramatic is happening, the Active Queries panel
still refreshes on its own schedule.

The SQL, unvarnished

The thing dev.to tutorials usually hide — the actual SQL — is the part I find
most useful. Here is the query powering the Active Queries panel, straight
from src/main/adapters/postgres-adapter.ts:

SELECT
  pid,
  usename AS user,
  datname AS database,
  state,
  COALESCE(
    EXTRACT(EPOCH FROM (now() - query_start))::text || 's',
    '0s'
  ) AS duration,
  COALESCE(EXTRACT(EPOCH FROM (now() - query_start)) * 1000, 0)::bigint AS duration_ms,
  query,
  wait_event_type || ':' || wait_event AS wait_event,
  application_name
FROM pg_stat_activity
WHERE state != 'idle'
  AND pid != pg_backend_pid()
  AND query NOT LIKE '%pg_stat_activity%'
ORDER BY query_start ASC NULLS LAST

Two details worth calling out:

pid != pg_backend_pid() filters out the monitoring query itself. Without this, you spend ten minutes wondering why there is always a query running.
query NOT LIKE '%pg_stat_activity%' is a belt-and-braces filter for the case where another client is ALSO polling this view. When I skipped it, the dashboard kept showing "the monitoring client is monitoring itself."

The cache-hit ratio query is where people usually copy-paste wrong:

SELECT
  CASE WHEN SUM(heap_blks_hit) + SUM(heap_blks_read) = 0 THEN 0
    ELSE ROUND(SUM(heap_blks_hit)::numeric / (SUM(heap_blks_hit) + SUM(heap_blks_read)) * 100, 2)
  END AS buffer_cache_hit_ratio,
  CASE WHEN SUM(idx_blks_hit) + SUM(idx_blks_read) = 0 THEN 0
    ELSE ROUND(SUM(idx_blks_hit)::numeric / (SUM(idx_blks_hit) + SUM(idx_blks_read)) * 100, 2)
  END AS index_hit_ratio
FROM pg_statio_user_tables

The CASE guards against division by zero on freshly restarted databases.
Without them, the panel shows NaN% for the first few minutes after a
restart, which is exactly when you are most likely to be looking at it.

The lock detection join

The Locks panel is the only query I am genuinely proud of. The canonical
"blocked by whom" join in Postgres is notoriously ugly because pg_locks
does not give you a single "blocker pid" column — you have to self-join on
every distinguishing column:

FROM pg_locks blocked
JOIN pg_stat_activity blocked_activity  ON blocked.pid = blocked_activity.pid
JOIN pg_locks blocking ON (
  blocked.locktype       = blocking.locktype
  AND blocked.database   IS NOT DISTINCT FROM blocking.database
  AND blocked.relation   IS NOT DISTINCT FROM blocking.relation
  AND blocked.page       IS NOT DISTINCT FROM blocking.page
  AND blocked.tuple      IS NOT DISTINCT FROM blocking.tuple
  AND blocked.virtualxid IS NOT DISTINCT FROM blocking.virtualxid
  AND blocked.transactionid IS NOT DISTINCT FROM blocking.transactionid
  AND blocked.classid    IS NOT DISTINCT FROM blocking.classid
  AND blocked.objid      IS NOT DISTINCT FROM blocking.objid
  AND blocked.objsubid   IS NOT DISTINCT FROM blocking.objsubid
  AND blocked.pid != blocking.pid
)
JOIN pg_stat_activity blocking_activity ON blocking.pid = blocking_activity.pid
WHERE NOT blocked.granted AND blocking.granted

IS NOT DISTINCT FROM is the operator that treats NULL = NULL as true,
which matters because most of these columns are NULL for any given lock type.
If you use plain = here, the join silently returns zero rows and you
conclude that nothing is blocking anything. Ask me how I know.

The kill button

async killQuery(config, pid) {
  const client = new Client(buildClientConfig(config, tunnelOverrides))
  await client.connect()
  const result = await client.query('SELECT pg_cancel_backend($1) AS cancelled', [pid])
  const cancelled = result.rows[0]?.cancelled === true
  return cancelled
    ? { success: true }
    : { success: false, error: 'Failed to cancel query - process may have already completed' }
}

pg_cancel_backend sends SIGINT to the backend process. It is the polite
version — pg_terminate_backend is the hammer, and I deliberately do not
expose it from the UI because killing a backend mid-transaction is a foot-gun
that no amount of confirm dialogs can save you from. If pg_cancel_backend
fails to stop the query, the assumption is that you want to keep looking
before escalating.

What I'd do differently

Two things I regret.

First, I hard-coded LIMIT 50 in the Table Sizes query. It was fine for my
own databases. Then someone with 12,000 tables opened the panel and their
disk groaned for nine seconds before anything appeared. A parameterized limit
with a default would have saved that. I will get to it.

Second, the refresh interval is per-panel but the polling is not staggered.
When all four panels refresh at 2s, they all fire at the same tick, and a
slow database sees four simultaneous connections every two seconds. Staggering
them by 500ms each would be gentler on the server. Classic premature
optimization trap — I built the simple version, shipped it, and only noticed
when a coworker complained.

Try it

If you want to see the Health Monitor without downloading anything, the
screenshots are in the data-peek README.
The code for this feature lives in src/renderer/src/components/health-monitor.tsx
and src/main/adapters/postgres-adapter.ts.

The app itself is at datapeek.dev — MIT source,
free for personal use, one-time license for commercial. I would rather you
read the SQL than click the download button, honestly. If it is the kind of
thing you'd want in your toolbox, the download is one click from there.

Supporting 3 Databases with One Codebase: The Adapter Pattern

Rohith Gilla — Tue, 16 Dec 2025 12:52:06 +0000

One of the core features of data-peek is supporting multiple database engines:

PostgreSQL - My primary database
MySQL - Still everywhere, especially in legacy systems
Microsoft SQL Server - Enterprise environments

The challenge: each database has different drivers, APIs, SQL dialects, and quirks. How do you support them all without turning your codebase into spaghetti?

The answer: the Adapter Pattern.

The Problem

Without abstraction, multi-database support looks like this:

// DON'T DO THIS
async function executeQuery(connection, sql) {
  if (connection.dbType === 'postgresql') {
    const client = new pg.Client(connection)
    await client.connect()
    const result = await client.query(sql)
    await client.end()
    return result.rows
  } else if (connection.dbType === 'mysql') {
    const conn = await mysql.createConnection(connection)
    const [rows] = await conn.execute(sql)
    await conn.end()
    return rows
  } else if (connection.dbType === 'mssql') {
    await mssql.connect(connection)
    const result = await mssql.query(sql)
    return result.recordset
  }
}

Now multiply this by every operation: connect, query, execute, getSchemas, explain, getTableDDL...

You end up with:

Massive if/else chains everywhere
Duplicated logic
Nightmare to add a new database
Impossible to test properly

The Adapter Pattern

The solution is to define a common interface and implement it for each database:

// db-adapter.ts

/**
 * Database adapter interface - abstracts database-specific operations
 */
export interface DatabaseAdapter {
  /** Database type identifier */
  readonly dbType: DatabaseType

  /** Test connection */
  connect(config: ConnectionConfig): Promise<void>

  /** Execute a query and return results */
  query(config: ConnectionConfig, sql: string): Promise<AdapterQueryResult>

  /** Execute multiple SQL statements and return results for each */
  queryMultiple(
    config: ConnectionConfig,
    sql: string,
    options?: QueryOptions
  ): Promise<AdapterMultiQueryResult>

  /** Execute a statement (for INSERT/UPDATE/DELETE) */
  execute(
    config: ConnectionConfig,
    sql: string,
    params: unknown[]
  ): Promise<{ rowCount: number | null }>

  /** Execute multiple statements in a transaction */
  executeTransaction(
    config: ConnectionConfig,
    statements: Array<{ sql: string; params: unknown[] }>
  ): Promise<{ rowsAffected: number; results: Array<{ rowCount: number | null }> }>

  /** Fetch database schemas, tables, and columns */
  getSchemas(config: ConnectionConfig): Promise<SchemaInfo[]>

  /** Get query execution plan */
  explain(config: ConnectionConfig, sql: string, analyze: boolean): Promise<ExplainResult>

  /** Get table definition (reverse engineer DDL) */
  getTableDDL(config: ConnectionConfig, schema: string, table: string): Promise<TableDefinition>

  /** Get available sequences (PostgreSQL-specific) */
  getSequences(config: ConnectionConfig): Promise<SequenceInfo[]>

  /** Get custom types (enums, etc.) */
  getTypes(config: ConnectionConfig): Promise<CustomTypeInfo[]>
}

Now the rest of the application just uses this interface:

// Anywhere in the app
const adapter = getAdapter(connection)
const result = await adapter.query(connection, sql)

No if/else. No database-specific code leaking everywhere.

Implementing an Adapter

Each database gets its own adapter class. Here's a simplified PostgreSQL adapter:

// adapters/postgres-adapter.ts
import pg from 'pg'

export class PostgresAdapter implements DatabaseAdapter {
  readonly dbType = 'postgresql'

  async connect(config: ConnectionConfig): Promise<void> {
    const client = new pg.Client({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.username,
      password: config.password,
      ssl: config.ssl ? { rejectUnauthorized: false } : false,
    })

    await client.connect()
    await client.end()
  }

  async query(config: ConnectionConfig, sql: string): Promise<AdapterQueryResult> {
    const client = new pg.Client(this.buildClientConfig(config))

    try {
      await client.connect()
      const result = await client.query(sql)

      return {
        rows: result.rows,
        fields: result.fields.map(f => ({
          name: f.name,
          dataType: this.mapOidToType(f.dataTypeID),
        })),
        rowCount: result.rowCount,
      }
    } finally {
      await client.end()
    }
  }

  async getSchemas(config: ConnectionConfig): Promise<SchemaInfo[]> {
    const client = new pg.Client(this.buildClientConfig(config))

    try {
      await client.connect()

      // Query information_schema for tables and columns
      const tablesResult = await client.query(`
        SELECT
          table_schema as schema,
          table_name as name,
          table_type as type
        FROM information_schema.tables
        WHERE table_schema NOT IN ('pg_catalog', 'information_schema')
        ORDER BY table_schema, table_name
      `)

      // ... fetch columns, primary keys, foreign keys

      return this.buildSchemaInfo(tablesResult.rows, columnsResult.rows, ...)
    } finally {
      await client.end()
    }
  }

  async explain(config: ConnectionConfig, sql: string, analyze: boolean): Promise<ExplainResult> {
    const explainSql = analyze
      ? `EXPLAIN (ANALYZE, FORMAT JSON) ${sql}`
      : `EXPLAIN (FORMAT JSON) ${sql}`

    const result = await this.query(config, explainSql)
    return {
      plan: result.rows[0]['QUERY PLAN'],
      durationMs: 0, // Extracted from ANALYZE output
    }
  }
}

The MySQL adapter is similar but handles MySQL-specific quirks:

// adapters/mysql-adapter.ts
import mysql from 'mysql2/promise'

export class MySQLAdapter implements DatabaseAdapter {
  readonly dbType = 'mysql'

  async query(config: ConnectionConfig, sql: string): Promise<AdapterQueryResult> {
    const connection = await mysql.createConnection({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.username,
      password: config.password,
    })

    try {
      const [rows, fields] = await connection.execute(sql)

      return {
        rows: rows as Record<string, unknown>[],
        fields: fields?.map(f => ({
          name: f.name,
          dataType: this.mapMySQLType(f.type),
        })) || [],
        rowCount: Array.isArray(rows) ? rows.length : null,
      }
    } finally {
      await connection.end()
    }
  }

  async explain(config: ConnectionConfig, sql: string, analyze: boolean): Promise<ExplainResult> {
    // MySQL uses different EXPLAIN syntax
    const explainSql = analyze
      ? `EXPLAIN ANALYZE ${sql}`
      : `EXPLAIN FORMAT=JSON ${sql}`

    const result = await this.query(config, explainSql)
    return {
      plan: result.rows[0],
      durationMs: 0,
    }
  }
}

The Adapter Registry

A simple factory function returns the right adapter:

// Adapter instances (singletons)
const adapters: Record<DatabaseType, DatabaseAdapter> = {
  postgresql: new PostgresAdapter(),
  mysql: new MySQLAdapter(),
  mssql: new MSSQLAdapter(),
  sqlite: new PostgresAdapter(), // Placeholder
}

/**
 * Get the appropriate database adapter for a connection
 */
export function getAdapter(config: ConnectionConfig): DatabaseAdapter {
  const dbType = config.dbType || 'postgresql'
  const adapter = adapters[dbType]

  if (!adapter) {
    throw new Error(`Unsupported database type: ${dbType}`)
  }

  return adapter
}

Adding a new database is now trivial:

Implement the DatabaseAdapter interface
Add it to the registry
Done.

The SQL Dialect Problem

The adapter pattern handles fetching data, but what about mutations?

When a user edits a row in the UI, I need to generate SQL:

-- PostgreSQL
UPDATE "users" SET "name" = $1 WHERE "id" = $2 RETURNING *

-- MySQL
UPDATE `users` SET `name` = ? WHERE `id` = ?

-- MSSQL
UPDATE [users] SET [name] = @p1 WHERE [id] = @p2

Same operation, different:

Aspect	PostgreSQL	MySQL	MSSQL
Parameter placeholders	`$1, $2, $3`	`?, ?, ?`	`@p1, @p2, @p3`
Identifier quotes	`"table"`	`table`	`[table]`
RETURNING clause	Yes	No	No (uses OUTPUT)

SQL Dialect Configuration

I created a dialect system to handle these differences:

// sql-builder.ts

interface SqlDialect {
  /** Parameter placeholder format */
  parameterPlaceholder: (index: number) => string
  /** Identifier quote character */
  identifierQuote: string
  /** Whether RETURNING clause is supported */
  supportsReturning: boolean
}

const DIALECTS: Record<DatabaseType, SqlDialect> = {
  postgresql: {
    parameterPlaceholder: (i) => `$${i}`,
    identifierQuote: '"',
    supportsReturning: true
  },
  mysql: {
    parameterPlaceholder: () => '?',
    identifierQuote: '`',
    supportsReturning: false
  },
  sqlite: {
    parameterPlaceholder: () => '?',
    identifierQuote: '"',
    supportsReturning: true // SQLite 3.35+
  },
  mssql: {
    parameterPlaceholder: (i) => `@p${i}`,
    identifierQuote: '[',
    supportsReturning: false
  }
}

Building Parameterized Queries

The SQL builder generates safe, parameterized queries:

function buildUpdate(
  operation: RowUpdate,
  context: EditContext,
  dialect: SqlDialect
): ParameterizedQuery {
  const params: unknown[] = []
  let paramIndex = 1

  const tableRef = buildTableRef(context, dialect)

  // SET clause
  const setClauses = operation.changes.map((change) => {
    const col = quoteIdentifier(change.column, dialect)
    const placeholder = dialect.parameterPlaceholder(paramIndex++)
    params.push(serializeValue(change.newValue, change.dataType))
    return `${col} = ${placeholder}`
  })

  // WHERE clause (primary keys)
  const whereClauses = operation.primaryKeys.map((pk) => {
    const col = quoteIdentifier(pk.column, dialect)
    const placeholder = dialect.parameterPlaceholder(paramIndex++)
    params.push(serializeValue(pk.value, pk.dataType))
    return `${col} = ${placeholder}`
  })

  let sql = `UPDATE ${tableRef} SET ${setClauses.join(', ')} WHERE ${whereClauses.join(' AND ')}`

  if (dialect.supportsReturning) {
    sql += ' RETURNING *'
  }

  return { sql, params }
}

Given this update operation:

{
  type: 'update',
  changes: [{ column: 'name', newValue: 'Alice', dataType: 'text' }],
  primaryKeys: [{ column: 'id', value: 42, dataType: 'integer' }]
}

The builder outputs:

// PostgreSQL
{ sql: 'UPDATE "users" SET "name" = $1 WHERE "id" = $2 RETURNING *', params: ['Alice', 42] }

// MySQL
{ sql: 'UPDATE `users` SET `name` = ? WHERE `id` = ?', params: ['Alice', 42] }

// MSSQL
{ sql: 'UPDATE [users] SET [name] = @p1 WHERE [id] = @p2', params: ['Alice', 42] }

Handling Special Types

Different databases have different data types. The builder handles serialization:

function serializeValue(value: unknown, dataType: string): unknown {
  if (value === null || value === undefined) {
    return null
  }

  // Handle JSON/JSONB - stringify objects
  if ((dataType === 'json' || dataType === 'jsonb') && typeof value === 'object') {
    return JSON.stringify(value)
  }

  // Handle arrays - PostgreSQL array syntax
  if (dataType.endsWith('[]') && Array.isArray(value)) {
    return value
  }

  // Handle booleans
  if (dataType === 'boolean' || dataType === 'bool') {
    return Boolean(value)
  }

  return value
}

Preview vs. Execution

For the UI, I also need human-readable SQL (not parameterized):

function buildPreviewSql(
  operation: EditOperation,
  context: EditContext,
  dbType: DatabaseType
): string {
  const { sql, params } = buildQuery(operation, context, dbType)

  // Replace placeholders with actual values (for preview only)
  let preview = sql
  params.forEach((param, index) => {
    const placeholder = getPlaceholder(dbType, index)

    let displayValue: string
    if (param === null) {
      displayValue = 'NULL'
    } else if (typeof param === 'string') {
      displayValue = `'${param.replace(/'/g, "''")}'`
    } else if (typeof param === 'boolean') {
      displayValue = param ? 'TRUE' : 'FALSE'
    } else {
      displayValue = String(param)
    }

    preview = preview.replace(placeholder, displayValue)
  })

  return preview
}

This is only for display. Actual execution always uses parameterized queries to prevent SQL injection.

Transaction Support

For batch edits (multiple INSERTs/UPDATEs), transactions ensure atomicity:

async executeTransaction(
  config: ConnectionConfig,
  statements: Array<{ sql: string; params: unknown[] }>
): Promise<{ rowsAffected: number; results: Array<{ rowCount: number | null }> }> {
  const client = new pg.Client(this.buildClientConfig(config))

  try {
    await client.connect()
    await client.query('BEGIN')

    const results: Array<{ rowCount: number | null }> = []
    let totalRows = 0

    for (const stmt of statements) {
      const result = await client.query(stmt.sql, stmt.params)
      results.push({ rowCount: result.rowCount })
      totalRows += result.rowCount || 0
    }

    await client.query('COMMIT')
    return { rowsAffected: totalRows, results }
  } catch (error) {
    await client.query('ROLLBACK')
    throw error
  } finally {
    await client.end()
  }
}

All edits succeed or none do.

The Benefits

This architecture has paid off:

1. Clean Separation

Database-specific code lives in adapters only. The rest of the app is database-agnostic.

2. Easy Testing

I can mock the DatabaseAdapter interface for unit tests:

const mockAdapter: DatabaseAdapter = {
  dbType: 'postgresql',
  query: jest.fn().mockResolvedValue({ rows: [...], fields: [...] }),
  // ...
}

3. Type Safety

The interface enforces a consistent API. TypeScript catches mismatches at compile time.

4. Extensibility

Adding SQLite support means implementing one class. No changes to the rest of the codebase.

Lessons Learned

Start with the Interface

I designed the DatabaseAdapter interface before writing any implementation. This forced me to think about the common API across databases.

Don't Over-Abstract

I initially tried to make the SQL builder handle every edge case. That was a mistake. Some things (like EXPLAIN syntax) are so different that database-specific code is cleaner than complex abstractions.

Test the Dialects

Each dialect needs its own test suite:

describe('SQL Builder', () => {
  describe('PostgreSQL dialect', () => {
    it('uses $1, $2 placeholders', () => { ... })
    it('uses double quotes for identifiers', () => { ... })
    it('includes RETURNING clause', () => { ... })
  })

  describe('MySQL dialect', () => {
    it('uses ? placeholders', () => { ... })
    it('uses backticks for identifiers', () => { ... })
    it('omits RETURNING clause', () => { ... })
  })
})

What's Next

The adapter pattern handles query execution. But there's another SQL challenge: parsing.

When a user writes multiple statements in the editor:

SELECT * FROM users;
INSERT INTO logs (message) VALUES ('test');
UPDATE users SET name = 'Bob';

I need to split these into individual statements. Sounds easy... until you encounter:

PostgreSQL dollar-quotes: $$ SELECT 'foo;bar' $$
MySQL backtick identifiers: `table;name`
Nested block comments: /* outer /* inner */ outer */
String literals with semicolons: 'hello; world'

That's the subject of the next post.

Next up: Adding AI to a Desktop App: 5 Providers, 18+ Models, Zero Lock-in

GitHub: github.com/Rohithgilla12/data-peek
Web: datapeek.dev

The Tech Stack Behind data-peek: Modern Desktop Development in 2025

Rohith Gilla — Mon, 15 Dec 2025 11:24:07 +0000

In the previous post, I explained why I built data-peek. Now let's talk about how I built it.

Choosing a tech stack for a desktop app in 2025 is... interesting. You've got Electron, Tauri, Flutter, native frameworks, and a dozen other options. Here's what I chose and why.

┌─────────────────────────────────────────────────────────────┐
│                    DESKTOP APPLICATION                       │
├─────────────────────────────────────────────────────────────┤
│  Frontend (Renderer Process)                                │
│  ├── React 19          UI framework                         │
│  ├── TypeScript        Type safety                          │
│  ├── Zustand           State management                     │
│  ├── Monaco            Code editor                          │
│  ├── TanStack Table    Data grid                            │
│  ├── TanStack Router   Navigation                           │
│  ├── shadcn/ui         Component library                    │
│  ├── Tailwind CSS 4    Styling                              │
│  └── @xyflow/react     ERD visualization                    │
├─────────────────────────────────────────────────────────────┤
│  Backend (Main Process)                                     │
│  ├── Electron 38       Desktop runtime                      │
│  ├── pg                PostgreSQL client                    │
│  ├── mysql2            MySQL client                         │
│  ├── mssql             SQL Server client                    │
│  ├── better-sqlite3    Local storage                        │
│  ├── electron-store    Encrypted settings                   │
│  └── Vercel AI SDK     LLM integration                      │
├─────────────────────────────────────────────────────────────┤
│  Build & Development                                        │
│  ├── electron-vite     Fast bundling                        │
│  ├── pnpm workspaces   Monorepo management                  │
│  ├── Vitest            Testing                              │
│  └── electron-builder  Distribution                         │
└─────────────────────────────────────────────────────────────┘

Let me walk through the key decisions.

Why Electron?

I know, I know. "Electron apps are bloated." "Use Tauri instead." I've heard it all.

Here's why I still chose Electron:

1. Mature Ecosystem

Electron has been around since 2013. VS Code, Slack, Discord, Figma (desktop), Notion... all Electron. That means:

Battle-tested in production at scale
Extensive documentation
Solutions for almost every problem on Stack Overflow
Large ecosystem of tools (electron-builder, electron-store, etc.)

2. Node.js Integration

I need to run database drivers. pg, mysql2, and mssql are Node.js packages. Electron gives me full Node.js in the main process.

With Tauri, I'd need to:

Write database connections in Rust
Bridge Rust to JavaScript
Maintain two language codebases

For a solo developer, that's a non-starter.

3. Development Speed

electron-vite gives me:

Hot module replacement in the renderer
Fast rebuilds (~100ms)
TypeScript out of the box
Same dev experience as a web app

I can iterate faster with Electron than any alternative.

4. Cross-Platform for Free

One codebase runs on macOS (Intel + Apple Silicon), Windows, and Linux. electron-builder handles code signing, notarization, auto-updates, and installers.

The Size Trade-off

Yes, Electron bundles Chromium. The app is ~150MB. But in 2025:

Storage is cheap
Download speeds are fast
Users don't care about 150MB (they care about functionality)

I'd rather ship a working app than a small broken one.

React 19: The UI Layer

React 19 brought some nice improvements:

Concurrent Features

// Suspense for data loading
<Suspense fallback={<SchemaLoader />}>
  <SchemaExplorer />
</Suspense>

useTransition for Responsive UI

const [isPending, startTransition] = useTransition()

const handleSearch = (query: string) => {
  startTransition(() => {
    setSearchResults(filterSchemas(query))
  })
}

Large schema lists (1000+ tables) stay responsive during filtering.

Why Not Vue/Svelte/Solid?

React's ecosystem is unmatched for what I needed:

Monaco React bindings - @monaco-editor/react just works
TanStack - Router and Table are React-first
shadcn/ui - It is slowly becoming the trivial solution when crafting interfaces.
Familiarity - I've shipped React apps for years

Could I build this in Vue? Sure. But I'd spend more time on tooling and less on features.

TypeScript: Strict Mode or Bust

Every .ts and .tsx file in data-peek is strictly typed:

{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "noUncheckedIndexedAccess": true
  }
}

Why It Matters

In a database client, type safety prevents disasters:

// Without strict mode, this compiles fine and crashes at runtime
function formatCell(value: unknown) {
  return value.toString() // 💥 value might be null
}

// With strict mode, TypeScript forces you to handle it
function formatCell(value: unknown) {
  if (value === null) return 'NULL'
  if (value === undefined) return ''
  return String(value)
}

Shared Types Package

The IPC contract between main and renderer is defined in a shared package:

packages/shared/src/index.ts

export interface Connection {
  id: string
  name: string
  host: string
  port: number
  database: string
  username: string
  password: string
  dbType: 'postgresql' | 'mysql' | 'mssql'
  ssl?: boolean
}

export interface QueryResult {
  rows: Record<string, unknown>[]
  fields: FieldInfo[]
  rowCount: number
  duration: number
}

Both processes import from @shared/*. If I change a type, TypeScript catches mismatches at compile time—not when a user runs a query.

Zustand: State Management That Doesn't Hurt

I've used Redux, MobX, Recoil, Jotai, and Context. Zustand is my favorite for mid-size apps.

11 Focused Stores

src/renderer/src/stores/
├── connection-store.ts    # Active connection, available connections
├── query-store.ts         # Query history, execution state
├── tab-store.ts           # Editor tabs
├── edit-store.ts          # Pending row edits
├── ddl-store.ts           # Table designer state
├── ai-store.ts            # AI chat sessions
├── settings-store.ts      # User preferences
├── license-store.ts       # License status
├── saved-queries-store.ts # Bookmarked queries
├── sidebar-store.ts       # Sidebar state
└── schema-store.ts        # Cached schema info

Simple API

// Define a store
export const useConnectionStore = create<ConnectionState>()(
  persist(
    (set, get) => ({
      connections: [],
      activeConnection: null,

      setActiveConnection: (conn) => set({ activeConnection: conn }),

      addConnection: async (conn) => {
        const connections = [...get().connections, conn]
        set({ connections })
      },
    }),
    { name: 'connections' }
  )
)

// Use it anywhere
function ConnectionSelector() {
  const { connections, activeConnection, setActiveConnection } = useConnectionStore()
  // ...
}

No providers, no boilerplate, no action creators. Just functions.

Persistence Built-In

persist(
  (set, get) => ({ /* ... */ }),
  { name: 'connections' } // Saves to localStorage
)

Query history, saved queries, and settings survive app restarts.

Monaco: VS Code's Editor in Your App

Monaco is the editor that powers VS Code. It gives data-peek:

Syntax highlighting for SQL (PostgreSQL, MySQL, T-SQL)
Multi-cursor editing
Find and replace with regex
Keyboard shortcuts users already know
Theming that matches the app

Custom Configuration

<MonacoEditor
  language="sql"
  theme={isDark ? 'vs-dark' : 'vs'}
  options={{
    minimap: { enabled: false },
    lineNumbers: 'on',
    fontSize: 14,
    tabSize: 2,
    wordWrap: 'on',
    automaticLayout: true,
  }}
  onChange={handleQueryChange}
/>

Schema-Aware Autocomplete

Monaco's completion provider lets me inject schema context:

monaco.languages.registerCompletionItemProvider('sql', {
  provideCompletionItems: (model, position) => {
    const suggestions = getTableAndColumnSuggestions(currentSchema)
    return { suggestions }
  }
})

Type users. and see column suggestions. Type FROM and see table names.

shadcn/ui + Tailwind CSS 4

I didn't want to build a design system from scratch. shadcn/ui provides:

Copy-paste components - Not a npm dependency, actual source code
Radix primitives - Accessible by default
Tailwind styling - Customizable without fighting CSS

Component Examples

<Dialog>
  <DialogTrigger asChild>
    <Button variant="outline">New Connection</Button>
  </DialogTrigger>
  <DialogContent>
    <DialogHeader>
      <DialogTitle>Add Connection</DialogTitle>
    </DialogHeader>
    <ConnectionForm onSubmit={handleAdd} />
  </DialogContent>
</Dialog>

Tailwind CSS 4

The new version has:

CSS-first config - No more tailwind.config.js
Native CSS variables - Better theming
Smaller output - Only includes used classes

@theme {
  --color-primary: oklch(0.7 0.15 250);
  --color-background: oklch(0.98 0 0);
  --color-foreground: oklch(0.1 0 0);
}

Dark mode is a single class toggle:

<html className={theme === 'dark' ? 'dark' : ''}>

@xyflow/react: ERD Visualization

Building an Entity Relationship Diagram from scratch would take weeks. @xyflow/react (formerly React Flow) gave me:

Draggable nodes for tables
Edges for foreign key relationships
Mini-map for navigation
Zoom/pan controls
Custom node components

I added collision detection on top (more on that in a future post).

The Monorepo Structure

data-peek/
├── apps/
│   ├── desktop/          # Electron app
│   └── web/              # License API + marketing site
├── packages/
│   └── shared/           # Shared TypeScript types
├── docs/                 # Documentation
├── seeds/                # Test database seeds
├── pnpm-workspace.yaml
└── package.json

Why pnpm?

Fast - Symlinks instead of copying
Strict - No phantom dependencies
Workspaces - Native monorepo support

Workspace Commands

# Run dev for desktop only
pnpm --filter @data-peek/desktop dev

# Build all workspaces
pnpm build

# Lint everything
pnpm lint

Build & Distribution

electron-vite

Vite-based bundling for Electron:

// electron.vite.config.ts
export default defineConfig({
  main: {
    build: { rollupOptions: { external: ['pg', 'mysql2', 'mssql'] } }
  },
  preload: {
    build: { rollupOptions: { external: ['electron'] } }
  },
  renderer: {
    plugins: [react()],
    resolve: { alias: { '@': resolve('src/renderer/src') } }
  }
})

Hot reload in the renderer, fast rebuilds in main process.

electron-builder

Handles everything for distribution:

# electron-builder.yml
appId: com.datapeek.app
productName: data-peek
mac:
  target: [dmg, zip]
  hardenedRuntime: true
  notarize: true
win:
  target: [nsis]
linux:
  target: [AppImage, deb, tar.gz]
publish:
  provider: github

One command builds for all platforms:

pnpm build:mac
pnpm build:win
pnpm build:linux

What I'd Do Differently

Consider Wails for v2

If I were starting fresh with more time, I'd seriously look at Wails. Since it uses Go for the backend, I could leverage my Go experience and avoid the Rust learning curve. The smaller binary size compared to Electron is compelling too.

More Tests from Day One

I added tests late. The SQL builder and parser now have good coverage, but UI tests are sparse.

Conclusion

The tech stack for data-peek prioritizes:

Developer productivity - Fast iteration, familiar tools
User experience - Responsive UI, native feel
Maintainability - Type safety, clear architecture
Cross-platform - One codebase, three platforms

Is it the "optimal" stack? Probably not. But it's the stack that let me ship a working product.

Next up: Supporting 3 Databases with One Codebase: The Adapter Pattern

Web
Github

Why I Built Yet Another SQL Client (And Made It Open Source)

Rohith Gilla — Fri, 12 Dec 2025 12:46:24 +0000

There are dozens of SQL clients out there. pgAdmin, DBeaver, DataGrip, TablePlus, Postico, Beekeeper Studio... the list goes on. So why build another one?

Because I was frustrated. And sometimes frustration is the best motivation.

The Problem

Here's my typical workflow as a developer:

Need to check something in the database
Open SQL client
Wait... and wait... (why is it loading plugins?)
Navigate through 47 menu options to find the query window
Write a simple SELECT * FROM users LIMIT 10
Get results buried under toolbars, status bars, and panels I never use

Every. Single. Time.

I didn't need an enterprise-grade database administration tool. I needed something that:

Opens fast - Under 2 seconds, not 20
Gets out of my way - Query editor front and center
Supports multiple databases - I work with PostgreSQL, MySQL, and SQL Server
Has keyboard shortcuts - Cmd+Enter to run, Cmd+K to navigate
Looks decent - Dark mode that doesn't burn my eyes at 2 AM

The Existing Options

Tool	Fast?	Simple?	Multi-DB?	Price
pgAdmin	❌	❌	❌	Free
DBeaver	❌	❌	✅	Free
DataGrip	✅	❌	✅	$229/year
TablePlus	✅	✅	✅	$89
Postico	✅	✅	❌	$50

The pattern was clear:

Free tools = slow and bloated
Fast tools = paid (and sometimes still bloated)
Simple tools = single database only

I wanted all four: fast, simple, multi-database, and free (for personal use).

Enter data-peek

So I built it. A SQL client with a simple philosophy:

Simple over feature-rich. Keyboard-first. Fast to open and query.

Here's what it looks like:

┌─────────────────────────────────────────────────────────────┐
│ [Connection ▾]                              [Settings] [AI] │
├──────────────┬──────────────────────────────────────────────┤
│              │                                              │
│  Schemas     │   SELECT * FROM users                        │
│  └─ public   │   WHERE created_at > '2024-01-01'            │
│     └─ users │   ORDER BY id DESC                           │
│     └─ posts │   LIMIT 100;                                 │
│     └─ ...   │                                              │
│              │   [Cmd+Enter to execute]                     │
│              ├──────────────────────────────────────────────│
│              │   id │ name  │ email          │ created_at   │
│              │   ───┼───────┼────────────────┼────────────  │
│              │   42 │ Alice │ alice@test.com │ 2024-03-15   │
│              │   41 │ Bob   │ bob@test.com   │ 2024-03-14   │
│              │                                              │
└──────────────┴──────────────────────────────────────────────┘

That's it. Schema browser on the left, query editor on top, results on bottom.

Core Features

What's In

Multi-tab query editor with Monaco (VS Code's editor engine)
PostgreSQL, MySQL, SQL Server support
Schema explorer with tables, views, columns, and stored procedures
Query history with execution time and row counts
Saved queries for frequently used SQL
Data export to CSV and JSON
Inline editing - Edit rows directly in the results table
ERD visualization - See your table relationships
AI assistant - Natural language to SQL (bring your own API key)
Dark mode - Because of course

What's Out (Intentionally)

Database administration tools
User management UI
Backup/restore wizards
47 toolbar buttons
Plugin systems
Startup splash screens
Feature bloat

Why Open Source?

I could have kept this private or made it fully paid. But here's my thinking:

1. I Use Open Source Every Day

My entire career is built on open source. PostgreSQL, React, TypeScript, Node.js, Linux... I've benefited enormously from others' contributions. This is my way of giving back.

2. Trust Through Transparency

A database client has access to your credentials and data. Would you trust a closed-source app from a solo developer? I wouldn't. With open source, you can:

Audit the code
See exactly how credentials are stored
Verify no telemetry or data collection
Build from source if you're paranoid (respect)

3. Community Makes It Better

I've already received pull requests that fixed bugs I didn't know existed and added features I hadn't thought of. The community sees edge cases I never would.

4. Sustainable Business Model

data-peek is free for personal use. Commercial use requires a license. This lets:

Individual developers use it for free forever
Companies that get value from it contribute financially
Me to keep maintaining and improving it

It's the same model as many successful open source projects.

The Tech Stack (Preview)

I'll do a deep dive in the next post, but here's the overview:

Electron - Cross-platform desktop (macOS, Windows, Linux)
React 19 - UI with modern hooks and concurrent features
TypeScript - Strict mode, because runtime errors are my nemesis
Zustand - State management that doesn't make me cry
Monaco - The editor that powers VS Code
Tailwind CSS 4 - Styling without the CSS file chaos

What's Next?

This is the first post in a series where I'll share:

The tech stack decisions and why I made them
The database adapter pattern for multi-DB support
Adding AI without vendor lock-in
Building the ERD visualizer with collision detection
Parsing SQL across dialects (harder than you'd think)

Try It Out

data-peek is available now:

GitHub: github.com/Rohithgilla12/data-peek
Downloads: macOS, Windows, Linux binaries in releases
License: MIT (free for personal use)

If you try it, I'd love to hear your feedback. Open an issue, start a discussion, or just star the repo if you think it's useful.

And if you're frustrated with your current SQL client too... maybe it's time to peek at something simpler.

Next up: The Tech Stack Behind data-peek: Modern Desktop Development in 2025

[Boost]

Rohith Gilla — Fri, 20 Jun 2025 02:33:41 +0000

Rohith Gilla

Jun 19 '25

Page Zen: The Open-Source Article Cleaning API You've Been Waiting For

#programming #go #api #productivity

Comments

3 min read

Page Zen: The Open-Source Article Cleaning API You've Been Waiting For

Rohith Gilla — Thu, 19 Jun 2025 15:34:29 +0000

In today's information-rich world, we're constantly bombarded with cluttered web articles filled with ads, popups, navigation menus, and other distractions. What if you could extract just the essential content from any article with a simple API call? Meet Page Zen - an open-source, self-hostable solution that transforms messy web articles into clean, readable content.

🚀 What is Page Zen?

Page Zen is a powerful Go-based API service that takes any article URL and returns clean, distraction-free content in multiple formats. Whether you're building a reading app, content aggregator, or just want to save articles without the clutter, Page Zen has you covered.

Key Features

✅ Clean Article Extraction - Removes ads, navigation, social widgets, and other noise

✅ Multiple Output Formats - Get content as clean text or markdown

✅ Open Graph Metadata - Extract rich social media metadata

✅ Medium Article Support - Works perfectly with Medium and other popular platforms

✅ Self-Hostable - Complete control over your data and infrastructure

✅ Open Source - MIT licensed, community-driven development

🌟 Why Choose Page Zen?

1. Open Source & Self-Hostable

Unlike proprietary services that lock you into their ecosystem, Page Zen is completely open source. You can:

Host it on your own infrastructure
Customize it for your specific needs
Never worry about API rate limits or service shutdowns
Maintain complete control over your data

2. Works with Any Article Platform

Page Zen intelligently handles content from various sources:

Medium articles ✨
News websites
Blog posts
Technical documentation
And virtually any web article!

3. Rich Metadata Extraction

Beyond just cleaning content, Page Zen extracts comprehensive Open Graph metadata:

Article title and description
Author information
Publication dates
Social media images
Twitter Card data
And much more!

🛠️ Easy to Deploy

Getting started with Page Zen is incredibly simple. The project includes Docker support for easy deployment:

# Clone the repository
git clone https://github.com/rohithgilla12/page-zen.git

# Run with Docker Compose
docker-compose up -d

That's it! Your article cleaning API is now running locally.

📝 API Usage Examples

Extract Article Content

curl -X POST http://localhost:8080/extract \
  -H "Content-Type: application/json" \
  -d '{"url": "https://itnext.io/essential-cli-tui-tools-for-developers-7e78f0cd27db", "include_markdown":true}'

Extract Open Graph Data Only

curl -X POST http://localhost:8080/opengraph \
  -H "Content-Type: application/json" \
  -d '{"url": "https://dev.to/gillarohith/develop-url-shortener-application-with-redwood-js-3cf7 "}'

Response:

{
  "url": "https://dev.to/gillarohith/develop-url-shortener-application-with-redwood-js-3cf7",
  "open_graph": {
    "title": "Develop URL shortener application with Redwood JS.",
    "description": "Develop URL shortener application with RedwoodJS            Introduction            What is...",
    "image": "https://media2.dev.to/dynamic/image/width=1000,height=500,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F77phvxr1c3i00fvv0jly.png",
    "url": "https://dev.to/gillarohith/develop-url-shortener-application-with-redwood-js-3cf7",
    "type": "article",
    "site_name": "DEV Community",
    "twitter_card": "summary_large_image",
    "twitter_site": "@thepracticaldev",
    "twitter_creator": "@gillarohith",
    "twitter_title": "Develop URL shortener application with Redwood JS.",
    "twitter_description": "Develop URL shortener application with RedwoodJS            Introduction            What is..."
  },
  "success": true
}

🎯 Perfect Use Cases

Content Aggregators: Build clean RSS feeds or news aggregators

Reading Apps: Create distraction-free reading experiences

Research Tools: Extract clean content for analysis

Social Media Tools: Get rich preview data for link sharing

Documentation: Convert web articles to clean markdown

🔧 Advanced Features

Page Zen goes beyond basic article extraction:

Image Processing: Converts complex picture elements to simple img tags
URL Resolution: Handles relative URLs and converts them to absolute paths
Smart Content Detection: Uses Mozilla's Readability algorithm for accurate content extraction
Configurable Cleaning: Remove specific elements based on your needs
Comprehensive Logging: Built-in structured logging for debugging and monitoring

🌍 Join the Community

Page Zen is more than just a tool - it's a community-driven project that welcomes contributions:

🐛 Report bugs and suggest features
💻 Contribute code and improvements
📖 Improve documentation
⭐ Star the repo to show your support

🚀 Get Started Today

Ready to clean up the web? Here's how to get started:

Try it locally: Clone the repo and run with Docker
Deploy to production: Use the included Dockerfile for easy deployment
Integrate: Start making API calls from your application
Customize: Fork the project and adapt it to your needs

Links:

🔗 GitHub Repository
📚 API Documentation

Page Zen - Because the web deserves to be readable.

Effortless Logging and Insights: Transform Your Flutter App with Telemetry.sh

Rohith Gilla — Sat, 31 Aug 2024 13:14:23 +0000

Why do I need logging?

Imagine this: You’re sipping your coffee, basking in the satisfaction of a smooth Flutter app deployment. Everything seems perfect until that message pops up—your app has a bug in production. Panic sets in as you frantically sift through code, wishing you had a crystal ball to see exactly what your users are experiencing. What if there was a way to capture crucial data at the moment it happens, giving you instant insights into those elusive bugs?

Telemetry.sh

Enter telemetry.sh—the tool you didn’t know you needed, until now. With just a few lines of code, you can start logging and tracking user behaviours, errors, and more, right from your Flutter app. It’s as simple as logging:



final response = await telemetry.log('user_${uid}', data);

In this post, we’ll dive into how you can harness the power of telemetry.sh

Setup

Setting up Telemetry.sh in your dart/flutter project is very simple.

Step 0

Register at Telemetry.sh
Get your API key

Step 1

If dart only project



dart pub add telemetry_sh

If flutter project



flutter pub add telemetry_sh

Step 2

Initialize the TelemetrySh instance with your API key



import 'package:telemetry_sh/telemetry_sh.dart';


final telemetry = TelemetrySh('YOUR_API_KEY');

Step 3

Log what you need :)



final response = await telemetry.log('table_name', data);

This tool behaves like a SQL database, where you can insert data in a table and query on it.

Then you can query the data in the console

How I like to use the tool

Telemetry.sh is incredibly versatile, and its flexibility allows you to structure your logs in a way that makes sense for your application. Here’s how I like to set it up for various scenarios.

Structuring Your Logs with Custom Tables

One of the best features of Telemetry.sh is that it treats your logs like entries in a SQL database. This means you can create different “tables” for different logging contexts. For example, let’s say you want to track user activities, errors, and API interactions separately. You can structure your logs like this:

• User Activity Logs: Use a table structure like user_activity_${uid} where uid is the user’s unique identifier. This allows you to track all activities performed by a particular user. Each log entry can include detailed data such as timestamp, action performed, and any relevant metadata.



final activityData = <String,dynamic>{
    'timestamp': DateTime.now().toIso8601String(),
    'action': 'clicked_button',
    'metadata': {'button_id': 'save_button'}
};
await telemetry.log('user_activity_${uid}', activityData);

• Error Logs: For error tracking, you can use a structure like error_logs. Each entry can capture the error message, stack trace, and any additional context that might be helpful for debugging.



final errorData = <String,dynamic>{
    'timestamp': DateTime.now().toIso8601String(),
    'error': 'NullPointerException',
    'stack_trace': errorStackTrace,
    'user_id': uid
};
await telemetry.log('error_logs', errorData);

• API Interaction Logs: If your app makes numerous API calls, it’s useful to log these interactions in a separate table like api_interactions. Here, you can store the request details, response status, and time taken for the request. This can help you diagnose issues related to API latency or failures.



final apiData = <String,dynamic>{
    'timestamp': DateTime.now().toIso8601String(),
    'endpoint': '/api/user/profile',
    'status': response.statusCode,
    'response_time_ms': duration.inMilliseconds
};
await telemetry.log('api_interactions', apiData);

Incorporating a robust logging solution like Telemetry.sh into your Flutter app isn’t just a nice-to-have; it’s a game changer. By structuring your logs effectively and leveraging Telemetry.sh’s powerful querying capabilities, you can transform your logging data into actionable insights. Whether you’re tracking user behaviours, debugging errors, or monitoring API performance, this tool empowers you to stay ahead of potential issues and continuously improve your app’s stability and user experience.

So, as you sip your coffee and watch your app thrive in production, remember that with Telemetry.sh, you’re not just logging data—you’re building a stronger, more resilient application. Happy coding!

Useful links
https://github.com/Rohithgilla12/telemetry_sh
https://pub.dev/packages/telemetry_sh

P.S. While I don’t own Telemetry.sh, I’m a big fan of the product, so much so that I wrote the Dart SDK for it as an open-source project.

Echo Diary: Your personal companion

Rohith Gilla — Mon, 13 May 2024 06:46:02 +0000

This is a submission for the Netlify Dynamic Site Challenge: Build with Blobs.

Important Links:
Github https://github.com/Rohithgilla12/echo-diary

Rohithgilla12 / echo-diary

What I Built

Welcome to Echo Diary, a cutting-edge personal diary app ingeniously crafted atop Netlify's robust Blob storage.

Echo Diary is more than just a diary; it's a secure vault for your thoughts, emotions, and memories, encrypted during transit for utmost privacy and security Blobs are safe since they are encrypted while transit, reference (https://docs.netlify.com/blobs/overview/#sensitive-data)

Key Features of Echo Diary:

Mood Tracker

Ever wondered about your emotional trends? Our Mood Tracker doesn't just record your feelings using expressive emojis; it transforms them into insightful graphs. This visual journey through your emotional landscape can help you understand life's ups and downs and foster personal growth.

Dynamic Entries

View on GitHub

Deployed App https://echo-diary.netlify.app/

What I Built

Welcome to Echo Diary, a cutting-edge personal diary app ingeniously crafted atop Netlify's robust Blob storage.

Echo Diary is more than just a diary; it's a secure vault for your thoughts, emotions, and memories, encrypted during transit for utmost privacy and security.
Blobs are safe since they are encrypted while transit, reference
(https://docs.netlify.com/blobs/overview/#sensitive-data)

Key Features of Echo Diary:

Mood Tracker

Dynamic Entries

Echo Diary lets you capture life as it happens. Whether it’s a quick text, a snapshot of a moment, or an audio recording, you can store multiple entries per day. Browsing through your past entries isn't just a walk down memory lane; it's a deep dive into your personal evolution, helping you reflect on your most significant moments.

Your Life, Encrypted, Secured, and Beautifully Plotted. Dive into Echo Diary today and start tracking your journey in a way that's secure, intuitive, and profoundly personal.

Demo

Dashboard

Add Entry

View Entries

Loom Video explaining the project

https://www.loom.com/share/a08f7b7c49f94322aa35d45d52fdd60d?sid=4073a958-5125-4787-b59e-1100ac6db98d

Platform Primitives

Leverage Netlify blobs as a database, used it to store user entries and moods.

Thanks to the Dev team and Netlify team for this amazing opportunity.