This course has been updated! We now recommend you take the API Design in Node.js, v4 course.

Check out a free preview of the full API Design in Node.js (using Express & Mongo) course:
The "Blog Schema Representation" Lesson is part of the full, API Design in Node.js (using Express & Mongo) course featured in this preview video. Here's what you'd learn in this lesson:

Scott spends a few minutes looking at a JSON representation of the schema for the blog application. After walking through the properties, he answer a few questions about migrating data to a new schema.

Get Unlimited Access Now

Transcript from the "Blog Schema Representation" Lesson

>> [MUSIC]

>> Speaker 1: So now that we know a little bit about creating schemas, and I say a little bit, I mean it's just a little bit. There's way more to this. But again, that's a whole separate thing. I could talk about Mongo and Mongoose for a week. We know just enough to get started with our API.

[00:00:17] So now that we do know that much, we'll use JSON again to blueprint how our resources are gonna look just like we did before. So remember we've got three resources, users, posts and categories. So I wrote some JSON down here to let you see what that looks like.

[00:00:34] So users, for now, all they have are user names, that's it, and they have to be unique. So here's an example what a user resource will look like. So an object with a user name and a string. Posts, they have a few things, four things actually. So they have a title and if you just look at the value you can kind of figure out what its type is, right?

[00:00:55] This is obviously a string. It has text, so this is the actually text of the blog post. If you look at the value, it's obviously a string. Author property, so the person who wrote this, if you look at this then, it's obviously an object ID. That's it's type, it's object ID.

[00:01:16] We have an array that's called categories, which is spelled wrong, but categories, and it is an array, a type of array, that has types of objects IDs inside of it. So it an array of object IDs.
>> Speaker 1: So we went over that so object IDs are this type and we already told you in arrays you can put whatever you want in there.

>> Speaker 1: So looking at these blueprints, just looking at the data that we spent out, you kinda know what these types are. And then for categories, all it has is a name, and it's a string, obviously. And it has to be unique. So a category is a name and it has be unique, you can't have more than one category with the same name.

[00:01:59] Doesn't make sense to do that. User names must be unique. Titles and posts, I guess they should be unique, you shouldn't have two blog posts with the same title. I don't know why you would do that.
>> Speaker 1: The blog post content, I don't think that needs to be unique.

[00:02:19] I guess you could if you want to stop somebody from writing the same blog post twice with a different title, I guess you could do that. It's up to you. But then the two important ones are, these are object IDs. And if you wanted to you can go ahead and add metadata on there if you want to like last seen, updated at career dot, although I'm pretty sure Mongoose should put that stuff on there, at least I thought I did.

[00:02:44] I thought I put the updated or created at properties and stuff on there. I think it does. I don't think it's showing up in Mongo though.
>> Speaker 1: So looking at the actual values of the adjacent above, we can infer what type of properties, or what type their properties are when we're creating our schemas.

[00:02:59] So again, when we start creating these schemas if you get lost and you're like what's this type again? Just come look at the value and just read it like, that's a string, that's a string, these are object IDs, these are strings.
>> Speaker 1: So any questions on that? Cuz now you're about.

[00:03:15] Yeah?
>> Speaker 2: We have a bunch kinda rolling in here.
>> Speaker 1: Okay.
>> Speaker 2: One question was about what about using things like using node-uuid to namespace things, so I think his idea is, instead of using the built-in object ID that they're using, can you tell it how to format that object ID?

>> Speaker 1: I don't know of a way of how you can tell it to format the object ID, but there's nothing stopping you from using node-uuid to attach another ID to your schema and index that. So there's nothing wrong with that. It's weird cuz like I had this conversation with like five people like a week ago, the same thing, and I wanted to know what there concerns are as far as like having another unique identifier other then an object ID.

[00:03:59] Cuz I can't think of like something that would concern me but they obviously know something that I don't know so I wanna know what they're thinking so I would love to talk to that person who made that question. Any other questions?
>> Speaker 2: I think I'm not sure I understand this one maybe, can you specify a type object ID for a particular collection?

[00:04:21] Like an author needs an object ID that belongs to a user document?
>> Speaker 1: So an author needs, can you specify a type object ID to a what?
>> Speaker 2: Particular collection.
>> Speaker 1: To a particular collection.
>> Speaker 1: I'm not too sure if I follow you or if I'm just over thinking it, but a type object ID to a particular collection.

>> Speaker 2: They might be asking can you specify the types of a collection? Collection of authors.
>> Speaker 1: No, a collection itself is not a type. So the only types, so you have all the built-in, well most of the built-in JavaScript types, so string, number, boolean, buffer, those are all built in to JavaScript.

[00:05:05] But then you have the types that are built in to Mongoose which belong in the mongoose.schema.types object. There's object ID, there's one that's called mixed, which means a smorgasbord of any type. But I'm pretty sure you cannot just say I want the owner to be the type of owner, or something like that.

[00:05:23] The way you do that is you pass in an object ID, what they reference, to the collection that it belongs to. But you can't just say owner right here. If that was the question, I think.
>> Speaker 2: Can you add custom functions to your models?
>> Speaker 1: Yes, we're gonna get there when we get to query.

[00:05:44] So you can totally do that.
>> Speaker 2: Is there a possibility of object ID collisions, if you have MongoDB running on multiple machines?
>> Speaker 1: If you have MongoDB running on multiple issues, if you have the same database running on multiple machines, then I think you're fine. Yes.
>> Speaker 2: If you want to change your scheme, is that it, schema, do you have to kind of re-spin all your current data into the new schema?

>> Speaker 1: Yeah. I thought you were just referring to code advisory question, and I thought you were referring to the question I was talking about. So yeah, as far as the object ID collision, no, if you have Mongo running on, the same database running on multiple machines, I guess maybe you, I dunno, you shredded your database, maybe?

>> Speaker 2: Yeah, that's what they're asking.
>> Speaker 1: Is that what they're asking for? No, you should be fine. So I don't think you'll have a problem with it.
>> Speaker 2: Then they're thinking like if you're using that as your user ID identifier, if you have Catastrophic.
>> Speaker 1: No, you should be fine.

>> Speaker 2: Okay.
>> Speaker 1: Yeah, you should be fine. What you were saying is, if you change the schema do you have to, so you were talking about like a migration. Do I have to take everything out and put.
>> Speaker 2: Like my business lives are changed.
>> Speaker 1: No, it's fine.

[00:06:53] It's just, if you change your schema, and you already have data that was using the old schema, right, it's not going to go re-validate all that stuff. It's not gonna be like, now this old data's not following the same validation, right? That may be good or bad. I'm not sure.

>> Speaker 2: It just sits there.
>> Speaker 1: It'll just sit there. So you gotta go.
>> Speaker 2: It's only data coming in that it validates.
>> Speaker 1: Right, right. There's no migration. So you can mainly set up migration if you wanted to. Or, I mean, a good thing is like having replication.

[00:07:20] And you do stuff with the replicated set, so. Okay.
>> Speaker 3: Another question was, they wanted to know if you've tried Orion DB, and they'd like to hear your opinion on it.
>> Speaker 1: I haven't tried Orion DB, it's literally like number three on my list of things to do.

[00:07:34] So I don't have any opinion on it other than if it's on my list, then it must be really good cuz I only put good things on my list. [LAUGH] So I wanna check it out. I don't have any opinions. If anyone else has used it before I would like to know because I heard it was awesome.

>> [NOISE]
>> Speaker 1: Is that it? We all caught up?
>> Speaker 2: I think so. They're just mentioning MongoDB doesn't scale well horizontally so that's, I guess you wouldn't be doing that is what they're saying?
>> Speaker 1: I mean, I guess you could say that. But it all comes down to like, yeah, relatively speaking it doesn't, yeah, I agree.

[00:08:16] But that doesn't mean it doesn't do it well, just if you compare it to other things. It's not meant for everything, [LAUGH] so I'll just say that. I'm not defending Mongo but I'm also not pushing it down anybody's throat, but it's definitely not meant for everything.