[Beginner] How to structure the following properly

[Kevin Toet]

Hello,

I've not done as much web/backend development as i could have. I come from a game programming background and i'm trying to setup a neat little API for our game studio's games. So this is a learning project for me in Node and Mongoose.

What i'm trying to achieve is a structure as following:

Developers [ not sure if a dev id is needed but atleast some form of login ]

     - Games [ should require an app token ]

          -Players [ list of people playing it, some light data available such as maybe name, avatar url and level ]

Players [ standard details + each player has x mb worth of space for save data ]

     - Friends [ list of friends they have + perhaps some actions they can execute with a timestamp ]

I've sort of susses out the dev -> games bit but that;s what things get confusing for me.

Writing this out i'm having a bit of a rubber ducky programming moment, but this means i have to setup 2 Schema's right? How would the relationship between the players look and the games? How do i not make this a huge mess?

-Cheers

[Ryan Wheale]

I found this article recently.  I think it should have been named "why mongodb is not the end all be all" - but worth a read if you are dealing with highly related data.  It was also written a while ago and doesn't mention mongoose (which handles relationships quite nicely), but it helped me realize that there's a time and place for different db technologies:

http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/  

For the record, I plan on using mongodb for most of my future projects, and just got done using it on a highly relational set of data... with great success - but here's why:

Your db technology and schema decisions should depend on the queries you are going to make (read that slowly, let it sink in).  The main benefit you are going to get from mongo is the ability to get a lot of data in a single payload.  Mongo is really really fast at this.  As soon as you start needing to make multiple queries to get everything you need for a single state of the app, then you might want to consider a db technology that is optimized for that type of work (think views, stored procedures, db-level caching, relational db stuff).  In my recent project, we stored "enough" duplicate data (eg. users names, etc - stuff that will never change) - as duplicate data so that we wouldn't need to query the users table when getting a list of articles.  The risk is that if a user's last name changes (rarely), then we have to go and update all of the nested data.  That was a risk we took (running with scissors, we call it).  

Another piece of advise I have is if you are about to design your database around mongo, you will need to abandon everything you know about relational databases.  The thought process is completely different, and until you can separate your years of experience with sql - you are going to find yourself trying to bend mongo into being a relational db... which it's not.

Lastly - don't neglect indexing.  It's not the easiest concept in mongo, as most of your "proper" indexing is going to involve complex indexes based on multiple fields with different ordering.  Try and perform "lean" queries whenever you can, try and specify only the fields you need, and take the time to learn aggregation.

Good luck.

~Ryan

--
Documentation - http://mongoosejs.com/
Plugins - http://plugins.mongoosejs.com/
Bug Reports - http://github.com/learnboost/mongoose
Production Examples - http://mongoosejs.tumblr.com/
StackOverflow - http://stackoverflow.com/questions/tagged/mongoose
Google Groups - https://groups.google.com/forum/?fromgroups#!forum/mongoose-orm
Twitter - https://twitter.com/mongoosejs
IRC - #mongoosejs
---
You received this message because you are subscribed to the Google Groups "Mongoose Node.JS ODM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongoose-orm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Toet]

Thank you so much for the explanation, Ryan. I was indeed trying to figure out how to setup relational data.

I'm a little insistent on using mongo as it's part of my exercises/studies with node.js. My approach to the current problem would be to have 3 Schema's

1 for developers that have an id

1 for Games that have a creator set to the id of the developer and have a list of users playing it.

1 for Users that have a game id (to which they belong), a list of id's of other users that are their friends and some space for game data (level, avatar, name, etc etc)

my url scheme (keeping CRUD in mind )would resemble something along the lines of

/developers                            //For developer account management

/games                                  //Game creation/deletion, each game get's a unique token

/games/:token                       //Edit a specific game

/games/:token/users             //List all users playing

/games/:token/users/:userid //CRUD operations for a specific user

With some extra methods for sending requests. Do i have the right approach in mind or am i grossly ignoring certain standards.

Please keep in mind i'm a game developer and this is my first ever experience in anything web backend related.

[Ryan Wheale]

Seems like a good starting point.  Again, focus on the queries you are making - there's no one-size-fits-all.  If you are doing multiple (~3+) populates() for every request, then you're using a screwdriver for a wrenches job.  Mongoose is a great library, but you should read the source code when you can as well as the mongodb docs.  Everything mongoose does is an operation on the mongodb native driver.  Understanding what's going on underneath the hood will help you write better queries and help you debug your code a little faster. For the REST service, I recommend reading up on it here:

http://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_web_services

In a nutshell, you should take advantage of the most basic URI and http verb schemes:

GET /games - gets all games (array)

GET /games/:id - get a single game (object)

POST /games - create a new game

PUT /games/:id - update a single game

DELETE /games/:id - delete a single game

Anything after that is up to you, the above is just your standard.  good luck

~Ryan