Jeu navigateur en 2016 : quelles technologies?

[Xenos]

Je ne vois pas de lien entre NodeJS et API REST (PHP fait très bien du REST aussi). Tu prends n'importe lequel de mes jeux que j'ai amorcé récemment (disons VariiSpace), et tu auras la possibilité d'avoir une version HTML, XML ou JSON de chaque page, en fonction du header HTTP "Accept". Donc, de là à en faire un REST, il n'y plus qu'un petit pas. Ceci n'est valable que lorsqu'OVH aura remis debout mon serveur... >.<

La différence majeure, pour moi, c'est que NodeJS est plutôt pour le "temps réel" (ou ce qui s'en rapproche) et la communication bi-directionnelle (client->serveur & serveur->client). PHP est plutôt pour de l'asynchrone et de la communication client->serveur uniquement (les bricolages de "push" ne sont pas formidables, et les lib qui l'émulent un peu mieux sont rarement compatibles sur un mutu; peut-être que PHP sera capable de faire du temps réel de manière plus "native" d'ici quelques années).

Mouais, vu la description (temps réel, réagir vite, actions en même temps entre tous les joueurs, le tout de manière fluide), je pense là encore qu'on est plutôt sur un jeu qui se ferait facilement via un SDK (quitte à exporter ensuite sur le web) plutôt qu'à coup de stacks à monter soi-même (qu'elles soient PHP ou JS).

[Patatruc]

A propos de l'hébergement node.js, il ne faut pas penser que c'est nécessairement très cher, on peut trouver des offres à prix modique voire même gratuites, par exemple chez Gandi (à partir de 4 euros). Il y en a d'autres de l'ordre de 3 à 7 euros par mois : viaduct.io, Heroku, DigitalOcean...

Une offre étonnamment généreuse est proposée par IBM Bluemix, avec 512 Mo de RAM et 1 Go de disque dur gratuit, sans limitation de bande passante. On peut y loger amplement une application gérant plusieurs centaines de connexions simultanées (j'ai poussé pour voir jusqu'à 800 connexions websockets sans problème). Entre parenthèses, ils font aussi tout le reste, PHP, Ruby etc.

[Argorate]

J'utilise les websocket oui et mon chat est temps réel avec NodeJS, ainsi que certaines actions du jeu qui sont pushé en temps réel.
Je pense que les websockets sont obligatoires en 2016 !

[Kaitos]

La différence majeure, pour moi, c'est que nodeJS est plutôt pour le "temps réel" (ou ce qui s'en rapproche) et la communication bi-directionnelle (client->serveur & serveur->client).

Tout à fait, d'où l'idée d'utiliser node.js pour la partie de mon jeu (en temps réel).

je pense là encore qu'on est plutôt sur un jeu qui se ferait facilement via un SDK

Pourquoi cette idée? Comme dis plus haut dans le topic, la partie temps réel correspond à 1/3 voir même 1/4 du code. Tout le reste est du web très classique.
De plus, je ne connais aucun SDK... Est-ce simple a coder ? Et en terme de coût (temps et argent)? N'est-ce pas sortir la trop grosse artillerie ?

A propos de l'hébergement node.js, il ne faut pas penser que c'est nécessairement très cher, on peut trouver des offres à prix modique voire même gratuites

Super, je ne pensais pas que c’était aussi accessible!

J'utilise les websocket oui et mon chat est temps réel avec NodeJS, ainsi que certaines actions du jeu qui sont pushé en temps réel.
Je pense que les websockets sont obligatoires en 2016 !

Parfait, quel(s) langage(s) et frameworks utilises-tu ? Et niveau architecture ?
As-tu déjà couplé nodeJS avec une autre technologie ?

[Sephi-Chan]

Node.js est adapté pour la partie Web classique autant que la partie temps réel (et ce n'est pas le seul). Tu n'as même pas besoin d'avoir une stack hétérogène.

[Kaitos]

Je ne vois pas de lien entre NodeJS et API REST

T'as déjà essayé de faire un petit essai de nodeJS + Express + MongoDB? =)

Node.js est adapté pour la partie Web classique autant que la partie temps réel (et ce n'est pas le seul). Tu n'as même pas besoin d'avoir une stack hétérogène.

Effectivement, mais je me méfie de NodeJS pour une application de cette envergure en terme de maintenabilité (Maturité du langage, syntaxe et mécanismes de scope/callbacks du JS par exemple) . Surtout qu'une grande partie des mécanismes de mon jeu n'ont aucunement besoin d'asynchronisme.
Voila la raison première pour laquelle je voulais coupler node avec une autre technologie. (Java ou PHP par exemple)

[Sephi-Chan]

Un paquet d'outils permettent de faire des API REST. Node n'est ni parmi les meilleurs, ni parmi les plus mauvais à ce petit jeu.

Même si Node ne fait pas partie des outils que j'utilise, je le trouve plus adapté que PHP pour tout : il est bon à la fois pour faire du temps réel (WS et SSE) que du bon vieux HTTP. La technologie est testée sous toutes les coutures (et bien ancrée dans la culture des tests automatisés) et très dynamique. Après, c'est sûr qu'il faut s'habituer à coder en Javascript, mais au moins c'est une compétence transférable.

Il n'y a rien que PHP fera mieux que Node, et il y a un tas de choses que Node fera mieux que PHP (temps réel, background/scheduled jobs…), inutile de s'encombrer d'Apache ou de PHP (tout au plus un Nginx pour servir les assets…).

[Xenos]

Je suis d'accord qu'une stack hétérogène est très chiante à gérer et ne sera probablement pas une bonne solution.

[Patatruc]

Maturité du langage, syntaxe et mécanismes de scope/callbacks du JS par exemple

Si tu prends une version récente de node.js (d'ailleurs y a aucune raison de pas le faire), tu as une compatibilité à 99% avec ECMAScript 6, en particulier tu peux utiliser le mot-clé let pour les déclarations de portée bloc. C'est beaucoup plus "propre" que var.

Si l'énorme permissivité de javascript te fait peur (et ça serait complètement légitime ), tu peux aussi carrément essayer de programmer en TypeScript.

La librairie async offre une alternative relativement élégante aux "poupées russes" de callbacks.

[niahoo]

Personnellement j'utilise le langage Elixir et le framework web Phoenix qui intègre un serveur web de production haute performances gérant les websockets (ou le long polling) de façon transparente en plus des classiques controlleurs, vues, templates, etc.

Si tu était prêt à changer de langage pour ton nouveau projet, je te conseille d'y jetter un oeil. Sinon, NodeJs devrait être cool aussi.

Je n'utilise pas de bases de données ; si le besoin se fait sentir j'utiliserai comme toi Postgres, sauf si une base noSQL me suffit (et peut être que cette base noSQL sera Postgrès de toutes façons).

Si tu dois garder du PHP, Laravel est cool, Slim est sympa aussi, plus petit et largement suffisant si tu te cantonnes à du REST (en plus des librairies utilisées pour ton jeu). CodeIgniter m'a laissé un goût amer mais c'était il y a longtemps, j'a ouï dire qu'il avait bien évolué.