What you are essentially asking for is a "JOIN" as in SQL. Your first point of reading should be that MongoDB does not do joins. The general concept here is "embedding" where the related information is actually contained within the document.
A good reading of the Data Modelling section of the official documentation can cover various points such as this and alternate approaches. But in most cases the data you wish to reference should just be part of the original document:
{
"_id" : ObjectId("53c66f922e15c4e5ee2655af"),
"name" : "alien-kindergarden",
"title" : "Alien Kindergarden",
"description" : "Alien description",
"gameCategory" : "GAME_CATEGORY_POPULAR",
"deviceOrientation_id" : "1",
"position" : "1"
}
This is generally because the MongoDB concept of being "scalable" is that all operations only ever deal with one collection at a time and "JOINS" are not attempted.
There are options available under node.js such as Mongoose that allow you to .populate()
items from another "related" collection. But the general problem here is that you cannot "query" on the "related" information. All this really implements is a "query behind the scenes" approach. So more than one query is actually executed. To find by "related" information the best approach is generally:
var catId = db.category.findOne({ "name": "GAME_CATEGORY_POPULAR" })._id;
db.category.find({ "gameCategory_id": catId })
As nothing will let you query the "game" collection by a value held in a foreign collection.
The idea of "embedding" and generally "duplicating" data might seem alien to those used to relational database concepts. But really your reason for applying a solution such as MongoDB should be that you realize certain "relational patterns" are not the "best fit" for your application.
If you have not looked at this in that way, then perhaps you should stick with the relational database approach and use those tools. At least until you "find" the actual shortcomings and realize why you need to "design" around that.
Unlearn what you have learned.