Missing Rails Console? Building a Database REPL for NestJS + Prisma

Christoph Grothaus — Thu, 11 Sep 2025 11:30:04 +0000

TL;DR: Coming from Rails/Phoenix, I missed having an interactive database console. So I built one for my NestJS + Prisma stack. Here's how and why.

The Problem: No Interactive Database Console 😢

If you've ever worked with Ruby on Rails or Elixir Phoenix, you know the joy of having an interactive console at your fingertips:

# Rails
rails console
> User.where(active: true).count
=> 1337

# Phoenix
iex -S mix
> MyApp.Repo.all(User)

These REPLs are game-changers for development. Need to quickly test a query? Explore your data model? Debug a complex association? Just fire up the console and start experimenting.

But when I switched to NestJS + Prisma... 🤷‍♂️

Sure, there's prisma studio for a GUI, but sometimes you just want to code your way through the data. You want to:

Quickly prototype complex queries
Test edge cases without writing full test files
Explore data relationships interactively
Debug production data issues with real queries

The Solution: DIY Database Console 🛠️

So I built my own (of course with a lot AI assistance by Claude Sonnet)! Meet the Prisma DB Console - a Rails-like interactive REPL for Prisma:

#!/usr/bin/env ts-node

import { PrismaClient } from '@prisma/client';
import repl from 'repl';
import util from 'util';

// Initialize Prisma with query logging
const prisma = new PrismaClient({
  log: [
    { emit: 'event', level: 'query' },
    { emit: 'stdout', level: 'error' },
    { emit: 'stdout', level: 'info' },
    { emit: 'stdout', level: 'warn' },
  ],
});

// Log SQL queries with params and timing
prisma.$on('query', (e) => {
  console.log('---');
  console.log(e.query);
  console.log(e.params);
  console.log(String(e.duration) + 'ms');
  console.log('---');
});

Key Features That Make It Awesome ✨

1. Prisma Client Pre-loaded

No more import boilerplate - just start querying:

db-console> await prisma.user.findMany()
db-console> await prisma.organization.count()

2. SQL Query Visibility

See exactly what SQL gets generated, with parameters and execution time:

---
SELECT "User"."id", "User"."email" FROM "User"
[]
12ms
---

3. Helpful Examples on Startup

Because who remembers all the Prisma syntax?

🚀 Prisma DB Console
📊 Prisma Client loaded as "prisma"
💡 Examples:
   await prisma.user.findMany()
   await prisma.tenant.count()
   await prisma.$queryRaw`SELECT COUNT(*) FROM "user"`
   await prisma.organization.findFirst({ include: { tenants: true } })

4. Clean Exit Handling

Properly disconnects from the database when you exit:

function cleanupAndExit() {
  console.log('\n👋 Disconnecting from database...');
  prisma.$disconnect()
    .finally(() => process.exit(0));
}

Usage: Simple as `npm run db:console` 🚀

Added it as an npm script for easy access:

{
  "scripts": {
    "db:console": "ts-node bin/db-console.ts"
  }
}

Now I can just run:

npm run db:console
# or
pnpm db:console

And I'm off to the races! Perfect for:

Data exploration: await prisma.user.findMany({ include: { profile: true } })
Quick counts: await prisma.order.count({ where: { status: 'PENDING' } })
Complex queries: await prisma.$queryRaw\SELECT * FROM ...``
Testing relationships: Verify those Prisma relations work as expected

The Real Impact 📈

Instead of:

Writing a throwaway script
Adding console.logs
Running the script
Deleting the script
Repeat...

I just:

Open console
Experiment
Done!

Want to Build Your Own? 🔨

The full implementation is about 70 lines of TypeScript. Key ingredients:

Node's built-in repl module
Your Prisma client
Event-based query logging
Proper cleanup handlers
Some helpful utilities in the REPL context

The beauty is in its simplicity - no external dependencies beyond what you already have in a NestJS + Prisma project. The full code of my db-console.ts is available on GitHub Gist if you want to copy and adapt it.

Closing Thoughts 💭

Sometimes the best tools are the ones you build yourself. They fit your exact workflow, solve your specific pain points, and give you that Rails-like developer experience you've been missing.

If you're working with NestJS + Prisma and find yourself constantly writing throwaway scripts to test database queries, consider building your own console. Your future self will thank you!

What is your experience in the NestJS + Prisma ecosystem? Did I miss out on an existing solution? Just drop a comment below!

gRPC client doesn't like Let's Encrypt cross-signed root certs

Christoph Grothaus — Thu, 14 Oct 2021 21:24:58 +0000

This is a story about gRPC client and a Let's Encrypt certificate chain that is cross-signed by two root certificates.

Our context

In one of our apps, we have a gRPC client that connects to a gRPC server of a 3rd party service that we use. The app is written in Ruby, thus we use the Ruby flavour of gRPC, which uses the gRPC core C library under the hood.

As many do, said 3rd party service uses SSL connections secured by Let's Encrypt (LE) certs. There is a certificate chain that goes from those per-service LE certs to a LE certificate authority (CA) cert, which again is signed by widely known root certs. In this case it even was cross-signed by two certs: DST Root CA X3 and ISRG Root X1.

The first one had been used by LE longer ago, to "get off the ground", as they write, because it was widely trusted. In recent times LE preferred the second, newer one, but still supported the older one via cross-sign.

On Sep. 30th 2021, that older DST Root CA X3 cert expired (see this Let's Encrypt blogpost explaining the background). While that shouldn't have been a problem, because the ISRG Root X1 was also part of the chain, this caused us troubles.

The problem

Last week – roughly one week after Sep. 30th – we restarted our app for the first time since weeks, through a deployment by CD pipeline. After restart, the gRPC client could not establish SSL connections to its gRPC server anymore. We got errors saying the server cert was invalid:

E1006 13:48:18.326843613      93 ssl_transport_security.cc:1446] Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.
GRPC::Unavailable: 14:failed to connect to all addresses.

After some digging, we found out there is a bug in the gRPC core C library. It didn't get it that there are two root certs in the chain, out of which one was still valid. It stuck with the invalid DST Root CA X3 cert, and thus failed cert verification.

Reportedly, only the core library – and by that all languages building on it, like Ruby or Python – was affected, but not the Java or the .Net version.

The solution

We could not wait for the bugfix. To get our app back running, we needed to persuade the gRPC client that the server cert indeed was valid. Therefore we removed the now-invalid DST Root CA X3 root cert from our Docker image, rebuilt the collection of CA certs, and forced gRPC to use that. That did the trick.

This is what we added to the Dockerfile (on a Debian base image):

# remove the now-invalid root cert
RUN rm /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
# rebuild collection of root certs
RUN update-ca-certificates
# force gRPC to use that collection
ENV GRPC_DEFAULT_SSL_ROOTS_FILE_PATH=/etc/ssl/certs/ca-certificates.crt

Meanwhile, the mentioned bug is fixed. But maybe you can't upgrade easily or quickly, so I hope this story helps some of you.

Further information

gRPC isn't the only one affected by this. The older OpenSSL version 1.0.2 also stumbles. This post arrives at the same solution, and also has a nice collection of links for more background information.

DEV Community: Christoph Grothaus