DEV Community: nahom kasa

I've just released VS extension AI git-Auto-commit v0.1.0 ! - Alt + O = git commit 🎉 No need for you API key.

nahom kasa — Wed, 30 Apr 2025 05:21:33 +0000

Hey devs,

I got tired of manually making commit messages, so I built a VS extension that auto-pushes changes when you press Alt + O. It uses AI to generate commit messages on its own.

I’m thinking of launching it, but I’ll decide based on the reaction this post gets. If I get 10+ likes, I’ll release it!

It’s open-source, so feel free to contribute.

Prisma + Neon DB Error P1001 Explained (with Pizza 🍕)

nahom kasa — Tue, 08 Apr 2025 15:49:01 +0000

🍕 Prisma and Neon DB: A Pizza Delivery Metaphor for Error P1001

So I was working on a project using Prisma and Neon DB, and I ran into this lovely error:

Error: P1001: Can't reach database server at `your-neon-url`

At first glance, it’s just a boring connection issue. But I realized the problem is actually super simple — and best explained with pizza 🍕.

Let me show you what I mean.

📦 Imagine This:

You’re a pizza delivery guy.

Someone places an order and sends you their location. You follow the map, drive all the way there, and then...

You’re outside the city. There's no house. Just a field. 🧍‍♂️

You call the number. Turns out they accidentally added a wrong number to their address. So you couldn't reach them.

This is exactly what happens when your DATABASE_URL is incorrect in your Prisma .env file.

Prisma is the delivery guy.

You (the developer) gave the delivery address (DB URL), but if you mistype even one character — Prisma won’t find the house. It’ll just stand there confused in a digital field.

📞 Scenario 2: Wrong Password = Stranger at the Door

You finally find the house, but when you knock, someone else opens the door and says:

“Yeah yeah, I ordered a pizza. Hand it over.”

But something feels off. You check the phone number — it doesn't match the order.

That’s what happens when your database password or user is wrong. Prisma finds the server, but it doesn’t trust the person who answered.

So again — the delivery fails.

🛠️ The Fix

Just like in real life:

Double-check the address Make sure your .env file has the right database URL, with no typos:

  DATABASE_URL="postgresql://your_user:your_password@your_neon_url/db_name"

Confirm your identity Ensure that the username and password actually match what Neon DB expects.

You can find your correct connection string inside your Neon dashboard. They even have a "Prisma" format ready to copy.

Once that’s fixed, run:

npx prisma db push

✅ Boom — your data (pizza) gets delivered.

🧠 Final Thoughts

Errors like P1001 seem technical, but they usually come down to:

Wrong address (host, port, DB name)
Wrong credentials (username/password)

Next time it happens, just think:

“If I were a pizza guy, could I find the customer and trust them enough to hand over the pizza?”

Your data is the pizza. Don’t let it get cold 🍕

Thanks for reading! If this helped you, leave a heart ❤️ or drop your own Prisma story in the comments.

Clerk, Webhooks, and Svix — A Story You'll Never Forget

nahom kasa — Mon, 07 Apr 2025 18:16:09 +0000

I’ve got a website. It’s connected to Clerk for authentication.

One day, my website tells Clerk:

"Hey Clerk, if you ever create a new user, send me a messenger and tell me about it."

Clerk’s like:

"Sure thing. Just give me the address to your office (your deployed site’s URL), and I’ll send the messenger there."

But my website is still in development, running on localhost:

“Hmm... Can you just send the guy to my house instead (localhost)?”

Clerk responds:

“Nah... I can’t reach houses. I only send messengers to real offices on the internet.”

So my website’s like:

“No worries. I’ll call a taxi (ngrok/localtunnel), and they’ll bring your messenger from your office to my house, and return them back.”

Now, things are cool… until the paranoia hits.

My website suddenly realizes:

“Wait a minute... What if some random guy pretends to be from Clerk? What if he tells me something like ‘You owe $1 billion in fake user debt?’ 😨”

So my website goes:

“Hey Clerk, how do I know it’s really your guy you’re sending me?”

Clerk smiles:

“Great question. I actually tattoo a signature on his head (cryptographic signature). You can call Svix, and they’ll tell you how to check that signature.”

My website’s like:

“Okay perfect. I’ll tell my taxi driver to snap a pic of the guy’s head and I’ll compare the tattoo to what Svix expects. If it matches, I’ll let him in. If not — kicked out.”

Then Clerk is like:

“You’re damn brilliant. We could even give the guy a T-shirt with a QR code instead of a tattoo, if that helps.”

And my website’s like:

“Yeah that works too. Fashion and security, baby. Let’s go.”

🔐 What Just Happened Technically

Clerk Webhooks: Tell you when users are created, updated, etc.

Your Localhost: Can’t receive messages directly, so you use ngrok to tunnel requests.

Svix: Validates that the message really came from Clerk.

Signature: Clerk signs the request (tattoo on the guy’s head).

You (your code): Use Svix’s library to verify the signature before trusting the message.

If you ever forgot how webhooks work — just remember the story of the guy, the taxi, the tattoo, and the QR code.

You’ll never look at API security the same again 😎

💥 Fixing "Invalid image file" Error When Uploading Videos to Cloudinary with Next.js

nahom kasa — Mon, 07 Apr 2025 15:06:49 +0000

While building a simple video uploader in Next.js, I ran into an error that took way longer to fix than I expected:

{ message: 'Invalid image file', name: 'Error', http_code: 400 }

If you're uploading videos to Cloudinary using upload_stream and hit this error, this post will save you hours.

🔍 The Problem
I was sending a video/mp4 file using formData from my frontend and handling the upload inside a Next.js POST route using upload_stream from the cloudinary Node.js SDK.

Here’s a simplified version of the code:

ts
Copy
Edit
const result = await new Promise((resolve, reject) => {
  const uploadStream = cloudinary.v2.uploader.upload_stream(
    { folder: "Videos" },
    (error, result) => {
      if (error) reject(error)
      else resolve(result)
    }
  )
  uploadStream.end(buffer)
})

The file was valid, the form data was working, and the backend received everything correctly. But it kept throwing this error:

css
Copy
Edit
{ message: 'Invalid image file', name: 'Error', http_code: 400 }
At first, I thought something was wrong with the file type or encoding.

Nope. The problem was simpler...

💡 The Real Issue
Cloudinary defaults to resource_type: "image" unless you explicitly tell it otherwise.

So even if you send a video file, Cloudinary still tries to process it as an image... and obviously fails.

✅ The Fix
Just add this to your upload_stream options:

ts
Copy
Edit
{ folder: "Videos", resource_type: "video" }
Now the full code looks like this:

ts
Copy
Edit
const result = await new Promise((resolve, reject) => {
  const uploadStream = cloudinary.v2.uploader.upload_stream(
    { folder: "Videos", resource_type: "video" },
    (error, result) => {
      if (error) reject(error)
      else resolve(result)
    }
  )
  uploadStream.end(buffer)
})

And just like that, the upload works.

🧠 Lesson Learned
Cloudinary expects you to declare what kind of file you're uploading. If you don’t specify, it defaults to "image", which can lead to confusing errors when you're actually uploading a video or something else.

Use resource_type: "image" for images (default)

Use resource_type: "video" for video files

Use resource_type: "raw" for other binary files like PDFs, zips, etc.

🚀 Final Thoughts
These kinds of small but painful bugs are a great reminder: tools often have smart defaults, but they’re not always smart enough. Knowing how they assume things can save you time.

If you found this helpful, follow me on Dev.to — I share real bugs I solve while building with Next.js, Cloudinary, and other full-stack tools.

Happy building!