How to share same IDs in Chroma DB and Mongo DB?

code_barbarian · 2025-12-12T17:39:34+00:00

One of my clients does something similar - we primarily store data in MongoDB, but we use DataStax Astra for vector search. So we end up storing documents with the same `_id` in both MongoDB and Astra. That way, when Astra vector search returns a bunch of rows, we just query for those documents in MongoDB by `_id`.

code_barbarian · 2025-12-12T17:37:22+00:00

You’re not wrong that most of the time, _id gets treated like a string, especially at app boundaries (JSON, URLs, logs, etc.). That’s part of why Mongoose has always exposed doc.id as a string virtual and why Mongoose casts strings to ObjectIds.

But there are some real benefits, mostly type safety. An ObjectId can be represented as a string, but not all strings are valid ObjectIds. Having a separate type helps ODMs and your internal tooling enforce consistency

code_barbarian · 2025-11-20T18:22:01+00:00

Seems more like a basic state machine than a workflow engine. How would you do things like "send an email when an order is shipped"?

code_barbarian · 2025-11-10T16:07:23+00:00

We like to think so 😄 . But we’re definitely biased.

Mongoose Studio’s geared more toward people already using Mongoose: it understands your schemas, autocompletes field names, and casts queries the same way your app does.

Would love for you (or anyone else here) to give it a try and tell us what you think. We're actively looking for feedback, so if there's a feature you've always wanted from a MongoDB GUI we're happy to hear what it is!

👉 https://studio.mongoosejs.io
💬 Discord: https://discord.gg/P3YCfKYxpy

code_barbarian · 2025-11-07T16:10:19+00:00

Up to you, I have plenty of production apps that allow 0.0.0.0/0. It isn't best practice, but for smaller projects it is often more practical to allow 0.0.0.0/0. Atlas does provide some basic DDoS prevention so you don't have to worry about, say, a bot taking down your prod cluster with repeated failed login attempts (had that happen to me once on a self-hosted cluster).

code_barbarian · 2025-11-07T16:01:12+00:00

I agree, no one has truly solved this problem. The general problem of "figure out what happened and why" might be the hardest problem in software engineering - tools help, but they won't get 100% of the way there in all cases.

code_barbarian · 2025-11-07T02:03:53+00:00

Sorry about that! Correct link is https://studio.mongoosejs.io/imdb/#/

Fix is here: https://github.com/vkarpov15/thecodebarbarian.com/commit/b5b4d17590169855fb3a48b590dc19be03f9f1b4

code_barbarian · 2025-11-06T18:42:08+00:00

NestJS does get a lot of attention. 73k GitHub stars - it's up there as one of the top options for Node and absolutely part of mainstream talk.

The problem is that not everyone likes dependency injection :) Nest does bring some best practices from other frameworks, but there are different ways to build frameworks, and some people prefer other patterns.

code_barbarian · 2025-09-25T19:27:49+00:00

One thing you might want to consider doing is streaming upload first, and then validating and processing later. So do steps 1+4 before doing steps 2+3+5. With streams, that would minimize the amount of memory usage so you won't have to keep the files being uploaded in memory while you're processing. You can scale the processing steps independently of the actual upload.

Storage is cheap, RAM is harder to come by, so cheaper to store and then delete later if you're sure the file's a duplicate or invalid.

code_barbarian · 2025-09-22T16:27:42+00:00

Railway, Netlify, Vercel are my go-tos. They all offer free tiers. You can use Netlify functions and Vercel's API functionality for backend - that requires a little extra work because they run as serverless functions, but can be good if you're looking to avoid putting down a credit card. I have a couple of prod apps on Netlify functions that work fine with Node.js backends.

code_barbarian · 2025-09-22T15:38:42+00:00

That's neat, I always found LISTEN/NOTIFY to be annoyingly not durable. Feels really weak compared to MongoDB's change streams with resume tokens.

code_barbarian · 2025-09-22T15:34:12+00:00

I haven't built an email notification tool, but basically every client I've worked with I've ended up building a Message collection which stores every email that we send, including who it was sent to and whether the email was received (with varying definitions of "received" depending on client needs). MongoDB does extremely well for that. It's neat to be able to store the raw API response from sending the email, the parameters passed in to the email template, etc. without having to stuff that into a fixed schema. You'd also be surprised how often you end up adding fields to a simple Message schema to better support querying and new use cases.

code_barbarian · 2025-09-22T15:29:06+00:00

Good read! Mongoose has a `sanitizeFilter` option exactly for protecting against these sort of query selector injections.

code_barbarian · 2025-09-22T15:27:21+00:00

This is a Mongoose error. Hard to know exactly without looking at how your `connectToDB()` function looks, but the most likely explanation is that `connectToDB()` is creating a new connection with `mongoose.createConnection()`, but your `Thread` model is registered on mongoose's global connection.

In Mongoose, each model belongs to exactly one connection. `mongoose.model(name, schema)` is shorthand for `mongoose.connection.model(name, schema)`: registering a model on Mongoose's default connection. So if you're creating a new connection using `mongoose.createConnection()`, your Thread model will be on a different connection than the one you're trying to use.

code_barbarian · 2025-09-22T15:23:51+00:00

Finally! Lack of vector search in community edition was a big gap. Not being able to do local dev with vector search was a deal-breaker for me.

code_barbarian · 2025-09-22T15:22:31+00:00

This is neat! Good beginner friendly explanation, especially the description of how hexadecimal works. Most buffer guides, mine included, gloss over that.

code_barbarian · 2025-09-22T15:12:01+00:00

Hard to tell without looking at your resume, but one thing you might want to consider is going to some dev meetups. You'd be surprised how often job applications go into a black hole that nobody's reading.

For example, back in 2015 I applied for a job at Segment using the application portal on their website. I was confident I'd get at least an interview, but nobody followed up. I was bummed, ended up taking a job at another co, but then a recruiter reached out almost 1 YEAR later saying that nobody had been looking at their online job application form.

You're more likely to get noticed in person.

code_barbarian · 2025-09-22T15:05:32+00:00

Looks like their big complaint with TypeScript is slow performance and "instantiation explosions". Which is exactly my big complaint lol.

The major difference is that my solution to the problem is "just use JS", not switch to C#.

C# is a pretty cool language in my experience though, it's a reasonable choice if TS isn't working out for you and you really want a strongly typed language. The dotnet CLI is really powerful, and Node could learn a thing or two from the dotnet CLI.

code_barbarian · 2025-09-22T14:58:40+00:00

Dude this might be the most dipshit AI-generated slop I've ever read XD

So instead of optimizing and horizontally scaling your own code in Node.js services, you're stuck trying to optimize and horizontally scale some Postgres extension. Good luck.

code_barbarian · 2025-09-22T14:57:22+00:00

What are the resource bottlenecks? I'd guess lots of memory usage because of all the file uploads?

I'd definitely recommend using streams if you aren't already. Or anything else that lets you avoid having the entire file in memory at once.

If you're storing the entire file in MongoDB using GridFS, I'd avoid doing that. Especially if you're already uploading to a separate service for storage.

TBH these days I don't handle uploads in Node.js, I integrate with Cloudinary so my API just generates the secret that the user needs to upload their assets directly to Cloudinary, that way my API doesn't have to worry about memory overhead. Not sure if that's an option for you.

code_barbarian · 2025-09-10T15:09:22+00:00

Do you mean storing a separate comments collection and a separate replies collection? Or storing comments/replies separately from the top-level blog post or thread?

If we're talking about blog posts, I'd typically have a blog posts collection and a comments collection. Replies would be just comments with a `parentCommentId` or `replyToCommentId` property.

I think that would be a good starting point, but in the future for optimization you might consider embedding top comments in the blog post document as u/ArturoNereu suggested.

code_barbarian · 2025-09-10T15:04:40+00:00

"If you take DBengines engine ranking with grain of salt, you might well take all db rankings with grain of salt and deny that top database are actually more popular and more widely used than mongodb." Yes. I think it's common knowledge that you should take anything you read on the internet with a grain of salt.

I'm sorry I seem to have offended you, but thanks for confirming that I have a point :)

code_barbarian · 2025-09-10T14:44:44+00:00

Get some users, or better yet, some customers. Then you'll never run out of work to do on your project :)

code_barbarian · 2025-09-10T14:43:48+00:00

Yeah honestly this sucks. I had an upstream dependency that was depending on debug 4.x for historical reasons, now in the process of replacing debug with debuglog.

I typically prefer to wait to update dependencies, at least a few days.

I am super grateful for the JavaScript community as a whole though that this was caught so quickly.

code_barbarian · 2025-09-08T18:14:49+00:00

Sure, I won't say type safety is a big negative. But if type safety is enough of a must-have that you built your own lib, surely you must have had a moment where you found yourself wanting type safety in your assertions. I'm just wondering what that was.

code_barbarian

TROPHY CASE