CODEWITHSUNDEEP
mongodbmeteor
Ido Ran
Ido Ran

Reputation: 11384

Meteor Data Model in Mongo

I'm evaluating server side frameworks and I'll be glad to hear what you think about the following problem with Meteor:

I have a working system which built from MongoDB, NodeJS and Angular.

I've design my data models in Mongo according to the needs of my system and common sense. For example, the system is based around the concept of a project that contain several components so I have a proejcts collection and inside the documents looks something like

{
  _id: ObjectId('123'),
  name: "Project A",
  components: [
    {
      compType: "type-A"
    },
    {
      compType: "type-B"
    }
  ]
}

Now I'm evaluating Meteor for the server side framework and after playing with it for a while, reading the documentation and looking at examples I see that even in the simple Todos example instead of modeling the data as list that contain the todos in it it is modeled as two separate collections.

I understand that it is done for the purpose of allowing DDP to sync only the data that is actually required for that specific client but it feels wrong for my to take my projects collection and split it just for the sake of helping DDP, mostly because it means I'm modeling my database according to the front-end needs and not the server needs.

Am I wrong about that feeling? What will happen if I'll model the Todos app with one collections lists and simply get update when new item is added to the list and not an update about the specific item?

Upvotes: 1

Views: 82

Answers (1)

Michel Floyd
Michel Floyd

Reputation: 20227

afaik DDP can synchronize sub-documents and changes to individual keys. The todos app probably used two distinct collections for other reasons besides optimizing for DDP. If you really want to understand how DDP works read more about it and watch websocket traffic in inspector. It shouldn't take you long to compare the two approaches to modeling todos.

Upvotes: 2

Related Questions