Imaging complex models made with One-to-Many One-to-One Many-to-Many relationships, etc… I want to archive the following, deserialise object from JSON request, validate it and save
Implementation in Java: http://www.mkyong.com/java/how-to-convert-java-object-to-from-json-jackson
Implementation with PHP: http://jmsyst.com/libs/serializer
Are you asking about the fundamental serialize/deserialize functionality? In JS it’s:
let string = JSON.stringify(obj)
//let prettyString = JSON.stringify(obj, null, 4) // would give "pretty-printed" output
let clone = JSON.parse(string)
Hi, thanks for you fast reply. I know about this feature.
Imagine complex neted trees/strucrures with different relationships, 1-m,1-1,m-m
What I want is to load model, push to frontend, let user make his changes.
Then get updated json from payload, validate it and send to database, by giving object class and paylod.
check links above, onece its being written, then it saves a lot of time
OK, but why would you do that within Meteor? Meteor gives you the full power of using (native) JSON (i.e. plain old JS) everywhere, from DB to frontend layer, and everything in a reactive fashion… Are you sure you’re not just thinking about this too much from the Java perspective (or PHP) where this really would have made sense since in any case you did have to de-/serialize stuff and had different code for backend and frontend and things were not reactive anyway etc.
With Meteor, why not just publish your collections as usual, nest documents to express your m:n relationships, then let the client update things as you like, and update the changed trees back into MongoDB?
You right, I came from PHP/MySQL world. 
I’m thinking how can I implement code abstractions for collections in meteor, without doing much hassle.
Maybe you can suggest how can I implement following with meteor:
Have you actually developed a proper project in Meteor? It sounds like you may not have.
You’re talking about big, complicated things. Meteor is all about keeping things as simple as possible, by building higher-level abstractions that take care of all the complex stuff. But it’s still about starting from a simple base and then increasingly fleshing things out.
You don’t sound like you have a very specific use case in mind, that’s why your thinking is too complicated. (Just my observation, and no value judgment intended!)
Start implementing the simplest possible thing that could work for your use case, and then take it from there. The path to how to adequately express more complex relationships will become quite obvious as you go.
There’s nothing super special about Meteor in that sense, you have all the power of Nodejs, MongoDB and browser-based JS libs at your disposal. You can do anything with Meteor that you can do with those technologies (and beyond). Just try to keep things simple, that’s an important value in Meteor-land, if I may observe and speak it that way.
Complex thinking without specific application is usually not useful. If you do have a specific use case, then express it and more specific answers might come.
For instance, what do you mean by “validation rules directly in entities”? What we do in Meteor is define a data model through a “schema” (the package is called “simple-schema”), and that also defines the validations and gives you ways to hook into validation.
“events” is a broad topic, so you’d need to narrow that down to what you mean specifically. There are packages that let you know when items have been added/changed/deleted in (mongo) collections, for example (search atmosphere for collection-hooks or so, not sure about exact package names).
“thin and abstract controllers” – Meteor doesn’t really do MVC/MVVM etc. We usually use a router like iron:router or flowrouter and build things with Blaze Templates. Some of us do angular, though I’m not sure how routing works in that case. Angular has its own “controller”-ish things, as I understand (not using it, personally). Some of us use React, and again here I’m not sure how routing works exactly.
For Angular there’s a page dedicated to the whole topic here: http://angular-meteor.com/
I really suggest you start building what you’re thinking about. You’ll find that things are really easy with Meteor, but you’ll have to adjust your thinking – simplify it, basically. Over here we don’t really call things “entities” (things are just objects, meaning plain JS objects/“maps” and arrays), we don’t talk about “thin” (we like simplicity in everything, so nothing is “fatter” than required), there is no meaning we assign to “abstract”, really (we do generalize concepts and create packages from them, but calling these things “abstract” would seem to subtract from the idea that everything ought to be as practical and pragmatic as possible); we don’t really talk about “views” (though the angularjs integration may, I don’t know? we have “templates” here and “helpers” which together define a data model and the (html) output generated from that).
Things are intentionally simple around here, including no-bullshit terminology, no overcomplicating things. Meteor and our packages handle the complexity so that in “userland” (user code) we can keep things very simple and easy to understand and fun to program and to maintain. 
(EDIT: Sorry for what may seem like a bit of a rant. Just felt like clarifying (some of) the idea of Meteor and its ecosystem a bit, since it felt like you’re a bit of a newcomer, not familiar yet with the ideas and values of the Meteor community!)
And linking you some of the packages I’m referring to:
https://atmospherejs.com/aldeed/simple-schema << “type” definition and validation
https://atmospherejs.com/aldeed/collection2 << goes well with the above
https://atmospherejs.com/matb33/collection-hooks << gives you hooks/events into things that happen to collection items
https://atmospherejs.com/iron/router << provides routing
Additional info for a good start with Meteor:
http://docs.meteor.com/#/full/ << provides excellent, almost complete docs for most of the “core” Meteor functionality; also works offline
http://devdocs.io/ << is a great companion for keyboard-based interaction with various docs from a single place; like for jquery (which is still useful and used with Meteor), lodash/underscore, ES6/ES2015 (new Array.map functions etc)
https://lodash.com/ // https://atmospherejs.com/stevezhu/lodash << excellent excellent excellent toolkit for all kinds of helper functions; highly recommended to also learn as you dive into Meteor
highly appreciate your answer, you tried to cover and explain as much as possible
You were right about me, I’m newbie to meteor, tried couple of tutorials/projects in opensource, also with meteor-angular
I wanted to implement REST in meteor, and looks like I just don’t need any serialising/deserialising in meteor because, we have reactive access to object(model/entity) it is for normal applications.
But if I would need to add REST Api to my project with 20+ entities, what would be the workflow? thats why I was asking about serialising/deserialising and pointing to Java and PHP in my first post.
Meteor is about “easy” development?
The problem is that for complicated problems, sometimes the right solution is not the easy one.
Sometimes the “easy” solution lead you to a path where everything becomes harder with the project size increasing.
We are actually debating if a global “Session” variable is a good thing or not, althought it is a known to be one of the worst coupling scenario.
When you look at usual applications developed for Meteor, you find a lot of antipatterns : application logic directly modifying the database, business code in templates helpers.
In the book “discover meteor” (whose authors are now part of MDG), they are saying :
Controllers?
It might be tempting to think of the file containing all of a
template’s helpers as a controller of sorts. But that can be ambiguous,
as controllers (at least in the MVC sense) usually have a slightly
different role.
So we decided to stay away from that terminology, and simply refer to
“the template’s helpers“ or “the template’s logic” when talking about a
template’s companion JavaScript code.
In a previous version of the book, they even invented a name for it, which i don’t remember exactly, which was something like a contraction of differents names. IMHO, this is a pointer that the role of this helpers is not clearly defined. This is a warning that there is no clear separation between view (template) code, business logic, and even database access. Everything is tightly coupled in what some could call “a big ball of mud”.
Last year, i have tried to apply traditionnal enterprise OO patterns to my meteor app, with a true domain model, a database Mapper, an identity map filled with my rich objects… I ended up coming back to quick and dirty Mongo objects hacking, since Meteor’s transparent reactivity didn’t work well once the objects were isolated from the DB.
Does it mean that Meteor (and in a more general view JS) is limited to small to medium projects ? I don’t know. Hopefully, some talented coders will come up with patterns allowing us to create clean, robust, uncoupled apps using the multiples benefits of Meteor.
I have come to the same conclusion: Meteor makes it easy to start and get a couple of things done really quickly but once your project grows it would be nice to separate domain logic, UI and database access just a bit more. Also: Refactoring is necessary as a project evolves and it becomes increasingly hard to keep track of all the places where for example a document is manipulated.
So for the last 1 1/2 years I have been working alongside other meteor projects on a Rich-Object Mapper. It is well tested and it has a “start” of a documentation. But now I am kind of stuck and need help.
Given that I’ve never open sourced anything, I am now looking for feedback on the idea and the concepts. I would very much appreciate any feedback and even say: It is needed in order for omm (thats the name) to move forward.
If you want take a look at it and share your thoughts, then please contact me via PM here.
You don’t really do “joins” so much. Think of each document as being separate but connected to each other by some data point. Mongo is very good at tree-like structures in this way. Say a user has multiple orders and an order has multiple products
{
_id: 1,
orderedAt: ISODate(),
products: [{
_id: 1,
quantity: 2
}, {
_id: 1,
quantity: 1
}]
}
Then think of a user having multiple orders.
{
_id: 1,
username: 'Jeff',
orders: [1, 2]
}
Your view could simply be implemented as follows.
each users
h1.title Orders for {{username}}
each orders
div.card
div.item.item-divider Order #{{_id}}
strong Products
each products
+Product.item
With helpers like:
users: function () {
return Meteor.users.find();
},
orders: function () {
return Orders.find({
_id: { $in: this.orders }
});
},
products: function () {
return Products.find({
_id: { $in: this.products.map(product => product.quantity) }
});
}
At no point are these really “joined” but they are similarly easy to work with despite them never being joined