Comment dois-je mon architecte DB & serveur API pour un jeu de société iPhone multi-tour par tour? (Penser à nodejs, mongo, canapé, etc.)

Question

Je travaille sur un jeu de société basé à son tour pour iPhone et éventuellement Android. J'utilise Appcelerator Titanium pour le développer. Ma conception multi-joueurs est similaire à mots avec des amis. Les utilisateurs se relaient lorsque vous êtes prêt, puis le plateau de jeu de l'adversaire est mis à jour en conséquence.

L'un de mes besoins est d'avoir une API de messagerie qui permet aux appareils des 2 joueurs de mettre à jour l'autre sur l'état du plateau de jeu après un déménagement. Songez à le faire avec JSON et de garder un objet JSON sur l'appareil qui contient à tout moment l'emplacement de toutes les pièces de plateau de jeu. Ceci est l'objet qui aura besoin de mettre à jour sur le périphérique local, puis envoyer un changement au dispositif de l'adversaire après un déménagement est fait.

J'ai APIs fait dans le passé pour les plates-formes mobiles et de le faire, je l'ai utilisé PHP avec MySQL et envoyé JSON-et-vient entre le serveur API et l'appareil mobile. Fonctionne dandy pour les utilisateurs simultanés bas, et généralement des applications non massives. En espérant celui-ci va se massif;)

Alors maintenant, au lieu d'un serveur httpd général et comme, je commence à penser à des prises persistantes et si elles sont nécessaires ou non pour mon nouveau jeu. Je pense aussi qu'il pourrait être intelligent de renoncer à la grande pile LAMP, et pour l'évolutivité et peut-être facilité de développement, de se pencher plus vers un flux de données de quelque chose comme Mongo / Couch -> Node.js -> iPhone. Je vais être honnête, ce serait ma première incursion dans un db non-sql et Node.js ainsi.

intéressé d'entendre les autres prend et expériences à ce sujet, plus d'options / pensées, et si je pense à la bonne façon, ou tout simplement créer des maux de tête pour moi-même.

Answer 1

Tout d'abord, NodeJS est génial pour écrire les proxys inverses TCP aux bases de données NoSQL. Vous pouvez laisser toutes les commandes standard passent à travers, mais modifier / étendre leurs API avec votre propre magie, par exemple faisant parler MongoDB HTTP ou CouchDB parlent un protocole binaire sur des sockets.

En ce qui concerne le choix d'une solution NoSQL pour stocker des morceaux de jeu de plateau et le suivi des mouvements des joueurs, je pense que ce soit Redis et CouchDB sont les meilleurs candidats.

1. CouchDB. Il est rapide, fiable, et peut gérer un grand nombre de connexions HTTP simultanées. Il est probablement la meilleure option, car contrairement à Redis il peut diffuser un message quand un change de document. change Continuous API ce super simple pour vous d'avoir fait le moniteur d'application de chaque joueur pour des modifications à leur conseil d'administration. La demande pourrait ressembler à:
   

   curl "$HOST/dbname/_changes?filter=app/gameboard&feed=continuous&gameid=38934&heartbeat=1000

   
   Chaque client recevra un objet JSON par ligne dans la réponse à tout moment un document pertinent est modifié. (Et une nouvelle ligne vide tous les 1000ms comme une sorte de keepalive.)
   
2. Redis. Il utilise un protocole à base de ligne simple (comme Memcached ++) pour parler sur un socket et vous permet de stocker des listes, des ensembles, avec arbitraires Hashes - même binaires - valeurs. Il est très rapide parce que tout se passe dans la mémoire, mais est conservée sur le disque de manière asynchrone. Mais vous devez surtout évaluer parce qu'il a déjà des notifications PubSub cuites au four dans. Notez que vous devrez publier explicitement les notifications de déplacement sur un canal les joueurs partagent parce que Redis ne publiera pas automatiquement lorsqu'un changement clé / valeur.

Depuis MongoDB ne dispose pas d'un mécanisme d'observation des changements comme-ils-se produisent ou faire PubSub je ne considère pas une bonne option, mais avec un effort supplémentaire que vous pourriez le faire fonctionner.

Pour conclure, vous pourrez peut-être remplacer « la grande pile LAMP » avec CouchDB seul, Redis seul, ou l'un placé derrière une application de noeud pour le filtrage / extension des API qu'ils fournissent déjà en quelque chose qui correspond à votre jeu.

Bonne chance!

Answer 2

Je viens de commencer l'apprentissage mongo, et il est pas difficile à apprendre. Des choses comme les index et les expliquer sont là et fonctionnent de la même. En ce qui concerne l'architecture, vous voulez penser à l'opposé de SQL; au lieu d'avoir une bonne raison de Dénormaliser, vous devez trouver une bonne raison de se normaliser. Les gars de 10gen (qui font mongo) diront que la pensée de hiérarchique est une façon plus naturelle de penser à des choses que je suis d'accord avec (provisoirement). Finders se sentent en quelque sorte sql-ish aussi bien, même si vous toujours utiliser la carte pour les requêtes-réduire l'agrégation.

D'après ce que je comprends canapé, la grande différence est qu'il ya une forte concentration sur la chose de réplication distribuée. Mongo se concentre davantage sur la performance sur des quantités massives de données (même si elles ont autosharding et une grande histoire d'échelle aussi). J'irais mongo, à moins que vous allez réellement utiliser les aspects distribués de canapé.

Node doit d'être la chose la plus cool jamais, et je pense que ce serait une grande application pour elle. J'ai aucune expérience avec elle, mais de ce que je l'ai lu, il est idéal pour les petites charges de demandes, et des échelles allant à merveille. javascript idiomatiques se prête assez bien à l'ensemble du modèle de concours complet, et avec v8 il fonctionne juste vulgairement rapide.