+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Discussion autour de l'architecture de l'application (/showthread.php?tid=6099)
RE: Discussion autour de l'architecture de l'application - archANJS - 22-04-2012
Merci, j'allais le proposer
Pour Redis et MongoDB, c'est bien ce qui me semblait en lisant les docs. Il serait donc possible d'utiliser les deux, non? Quoique personnellement s'il me fallait choisir entre les deux, je choisirais MongoDB (qui selon moi convient mieux au projet).
Je continue à regarder, je vous en donne des nouvelles.
RE: Discussion autour de l'architecture de l'application - niahoo - 22-04-2012
Avec erlang il faudrait utiliser le framework OTP pour mettre en place l'architecture du truc sans se prendre la tête et bénéficier de la tolérance aux pannes.
Voilà à quoi ressemble le code métier Sephi : http://spawnlink.com/otp-intro-1-gen-server-eb-server-deposit-api/index.html
C'est le code d'un compte bancaire, on peut poser et déposer de l'argent. y a pas de sauvegarde en base de données dans l'exemple. ça peut être utilisé par exemple pour gérer la thune d'un joueur. bien qu'à y réfléchir, ce genre de trucs n'ont pas besoin d'être concurrentes, il suffit de charger et décharger son compte pendant qu'on update le perso, lors de l'achat d'un item ou autre. Là il fait ça pour l'exemple.
tiré d'un tuto : http://spawnlink.com/articles/an-introduction-to-gen_server-erlybank/index.html
Non je me souvenais mal, après lecture ça gère tous les comptes de la banque. ton site peut faire plein d'accès concurrents aux thune de quelqu'un, ils passeront chacun leur tour par ce serveur, donc pas de problèmes de concurrence ou de race conditions. ensuite, à voir si c'est une bonne chose ou si ça ralentit trop.
RE: Discussion autour de l'architecture de l'application - archANJS - 23-08-2012
Je remonte le sujet, après un certain temps déjà. La situation a évolué, mais j'ai toujours quelques interrogations, et j'aurais besoin de votre avis sur ce coup-là.
Voici ce que ça donne jusqu'à maintenant:
1. Côté client
Langage: Javascript
Frameworks: Backbone.js et Marionette.js
Fonction: Interface de communication avec le client et de navigation.
Autres:
- Communication avec l'API fournie par l'application serveur.
2. Côté serveur
A) Application serveur
Langage: Ruby
Framework: Ruby on Rails
Fonction: Traiter les informations envoyées par l'utilisateur et relayer la suite au moteur de persistance (en ajoutant les tâches aux queues respectives), gérer les modules non-persistants (blog, forum, wiki, etc).
Autres:
- Communication avec la base de données avec MongoMapper.
- API RESTful, renvoyant du JSON à l'application cliente.
B) Moteur de persistance
Langage: Erlang
Framework: Aucun (pour le moment du moins)
Fonction: Exécuter les queues et tâches, assurer la persistance du monde virtuel.
Autres:
- Communication avec la base de données avec Mongrel.
C) Serveur de push
Langage: Javascript
Framework: Node.js
Fonction: Envoyer les données nécessaires au client par push.
Autres:
- Communication avec l'application cliente pour le push de données.
- Utilisation de Socket.io?
Alternative: Juggernaut
3. Base de données
Type: MongoDB
Avantages:
- Uniformisation de toutes les composantes logicielles sous un seul et même format de données (JSON).
- Séparation intelligente des couches de travail.
Désavantages:
- Beaucoup de langages/technologies.
- Autres?
Voilà .. qu'en dites-vous? Des questions, avis, commentaires, critiques? ^^
RE: Discussion autour de l'architecture de l'application - niahoo - 23-08-2012
Trop de trucs à mon avis.
Déjà, Rails. C'est écrit en ruby et pas en PHP donc on n'a pas il me semble 1 thread par requête. Tu peux avoir des objets persistants je pense non ? Ou du moins, tu as tous les outils qu'il faut pour gérer des queues, puisque tu ne cites que cette fonctionalité dans ce sujet.
Erlang: Si le but est de lancer des queues erlang depuis Rails, et de mettre mongoDb à jour depuis erlang, erlang a les pilotes qu'il faut pour s'y connecter directement. Ensuite il y a des librairies pour communiquer entre erlang et ruby. Je ne sais pas si communiquer par HTTP est un bon plan. Mais pourquoi pas.
Enfin, Node. Je pense que coupler Rails et erlang est un bon plan, rails sert tout le HTML et erlang tout le JSON. Et node aussi je pense, si tu es plus à l'aise en javascript ça peut être mieux, mais erlang est très sympa à découvrir (le langage s'apprend très vite, le framework est plutôt complexe je trouve.)
Dans les deux cas, Node ou Erlang, tu pourras gérer des queues (nickel pour erlang car tu auras une API synchrone), tu pourras faire du push avec socket.io ou sockjs. je pense que Erlang + Node c'est une mauvaise idée, tu iras plus vite avec un seul (et tu pourras faire du push depuis les queues ça peut être pratique ^^).
Quelques remarques :
Avec erlang, y a pas de framework web du niveau de rails. Pour servir du HTML c'est pas encore ça (y a quand même de super trucs, mais pas trop adaptables pour un jeu je pense). Bon, tu ne comptais pas le faire.
Erlang dispose de serveurs web parmi les plus rapides qui existent. Pour faire du push sur 2 - 3 URL c'est impec.
Bon pour node je sais pas mais j'ai l'impression qu'il y a beaucoup plus de tutos et de doc.
edit: hhmmm pas très clair tout ça .. sorry
RE: Discussion autour de l'architecture de l'application - Sephi-Chan - 23-08-2012
Idem. Je trouve cette stack trop importante et hétérogène : tu dois pouvoir rationaliser tout ça.
As-tu ai vraiment besoin de tout ça ?
RE: Discussion autour de l'architecture de l'application - archANJS - 23-08-2012
niahoo a écrit :Trop de trucs à mon avis.
Sephi-Chan a écrit :Idem. Je trouve cette stack trop importante et hétérogène : tu dois pouvoir rationaliser tout ça.
Voilà, c'est ce que je trouvais aussi.
Sephi-Chan a écrit :As-tu ai vraiment besoin de tout ça ?
J'ai "besoin" de toutes ces technologies (si on veut), mais le trop grand nombre de langages me rebute aussi ..
niahoo a écrit :Déjà, Rails. C'est écrit en ruby et pas en PHP donc on n'a pas il me semble 1 thread par requête. Tu peux avoir des objets persistants je pense non ? Ou du moins, tu as tous les outils qu'il faut pour gérer des queues, puisque tu ne cites que cette fonctionalité dans ce sujet.
Là tu vois, ça m'intrigue (pour la persistance des objets et les requêtes) .. Pour le truc des queues, je suis d'accord avec toi, il en existe (Resque et ResqueScheduler entre autre), mais bien que le fonctionnement se ressemble (queues, workers et tâches) ce n'est pas exactement le même but visé par le moteur de persistance.
niahoo a écrit :Erlang: Si le but est de lancer des queues erlang depuis Rails, et de mettre mongoDb à jour depuis erlang, erlang a les pilotes qu'il faut pour s'y connecter directement. Ensuite il y a des librairies pour communiquer entre erlang et ruby. Je ne sais pas si communiquer par HTTP est un bon plan. Mais pourquoi pas.
Oui, il y a bien des librairies (erlectricty et autres, si je ne m'abuse), mais ce n'est pas nécessaire. Parce que en fait, Erlang et Ruby n'ont pas à communiquer, et ne le feront pas (ou du moins, indirectement).
Il faut savoir que les actions du joueur sont traitées tout d'abord par Rails (après avoir passé par l'intermédiaire du client javascript). Généralement pour enrayer les erreurs / tentatives de hack, ou peu importe. Le fait est que, pour ce qui a trait au jeu lui-même, Rails ne fait rien (d'où le principe des queues). Rails enregistrerait, en base de données disons, dans la bonne queue l'action à traiter, et le moteur Erlang le ferait (que ce soit immédiatement, ou de façon asynchrone, avec un délai dans le temps).
Rails aurait tout accès aux données du jeu quand même (pour les classements), et n'embêterait pas Erlang pour les modules extérieurs (du genre blog, forum, wiki, etc). Dans ces cas-là, les actions seraient traitées directement par Rails.
niahoo a écrit :Enfin, Node. Je pense que coupler Rails et erlang est un bon plan, rails sert tout le HTML et erlang tout le JSON. Et node aussi je pense, si tu es plus à l'aise en javascript ça peut être mieux, mais erlang est très sympa à découvrir (le langage s'apprend très vite, le framework est plutôt complexe je trouve.)
Dans les deux cas, Node ou Erlang, tu pourras gérer des queues (nickel pour erlang car tu auras une API synchrone), tu pourras faire du push avec socket.io ou sockjs. je pense que Erlang + Node c'est une mauvaise idée, tu iras plus vite avec un seul (et tu pourras faire du push depuis les queues ça peut être pratique ^^).
S'il y en a un à balancer, c'est définitivement Node.js selon moi. Mais, d'où mon interrogation, dans ce cas-là Juggernaut peut-il tout effectuer seul? (pour le push et tout le tatim)
Oups, j'ai manqué un bout.
niahoo a écrit :edit: hhmmm pas très clair tout ça .. sorry
J'ai pu me débrouiller, c'est pas trop pire
niahoo a écrit :Quelques remarques :
Avec erlang, y a pas de framework web du niveau de rails. Pour servir du HTML c'est pas encore ça (y a quand même de super trucs, mais pas trop adaptables pour un jeu je pense). Bon, tu ne comptais pas le faire.
Oui, d'où le fait que je ne peux pas tout simplement utiliser Erlang pour l'intégral. Mais bon, ça fait un peu mon affaire. Et puis Rails est génial aussi.
niahoo a écrit :Erlang dispose de serveurs web parmi les plus rapides qui existent. Pour faire du push sur 2 - 3 URL c'est impec.
Bon pour node je sais pas mais j'ai l'impression qu'il y a beaucoup plus de tutos et de doc.
Ah, là tu vois, je savais pas; on peut faire du push avec Erlang? Tu as des liens/noms pour ces serveurs?
J'ai pas trop compris le truc des 2-3 URL par contre.
RE: Discussion autour de l'architecture de l'application - Sephi-Chan - 23-08-2012
On peut faire du push avec tout.
Parmi les serveurs Web il y a Yaws je crois.
RE: Discussion autour de l'architecture de l'application - archANJS - 23-08-2012
Sephi-Chan a écrit :On peut faire du push avec tout.
Parmi les serveurs Web il y a Yaws je crois.
J'ai du me confondre dans les termes et me mélanger; c'est plus clair maintenant.
Merci pour le nom, je regarde ça.
RE: Discussion autour de l'architecture de l'application - Akira777 - 24-08-2012
Tiens, merci pour ce sujet très intéressant. Je bosse sur le nouveau moteur de mon jeu par navigateur et je pars du même principe, un serveur de jeu et un serveur web pour le site.
De manière plus simple un moteur PHP sous CodeIgniter entièrement REST. Et le serveur site web qui ne fait que récupérer ce que j'appelle la "map relationnelle" du jeu. Ca me permet de produire mon jeu pour navigateur, Android, iOS & Facebook sans avoir de code à ré-écrire, mis à part la partie présentation. Et d'utiliser de manière optimale les fonctionnalités propres à chacun des supports (les notifications d'application pour iOS par exemple).
RE: Discussion autour de l'architecture de l'application - Maks - 24-08-2012
Il y a en beaucoup trop côté serveur à mon avis. Une architecture efficace selon moi est une architecture concentrée sur le moins de technologies possibles par rapport à ce que tu souhaites obtenir.
Node ou Rails il faut choisir. Pourquoi les deux ?
Se servir de Node comme serveur de push, c'est un peu comme aller acheter du pain en Ferrari.
C'est bien plus que ça. Je prêche un peu pour ma paroisse encore une fois, mais ça te permettrait en plus de n'avoir qu'un seul langage.
Donc Rails + Juggernaut ou Node + Socket.IO + (Express + Mongoose) || Tower (le stack classique)
En ce qui concerne Erlang, j'y connais rien, je comprends pas trop en quoi ça peut t'aider, donc je vais éviter de dire des conneries lol.