Rendu de canevas HTML5 côté client ou côté serveur pour une application de tableau blanc node.js?

Question

Je pensais qu'une petite application web de tableau blanc serait un bon moyen d'améliorer mes compétences node.js et JavaScript. J'ai vu quelques-uns sur le web, ce qui est logique car il semble idéal pour ce genre de pile. Juste en prenant un moment pour réfléchir, cependant, je me posais des questions sur les rôles du client et du serveur dans ce type d'application web. Trébuchant sur node-canvas, je suis devenu encore plus confus. De quoi, spécifiquement, le client et le serveur devraient-ils être responsables?

Si le serveur est capable de restituer un canevas, doit-il accepter et valider les entrées des clients, puis les diffuser à tous les autres utilisateurs connectés via socket.io? De cette façon, le serveur conserve un master -canvas élément de sortes. Une fois qu'un nouvel utilisateur se connecte, le serveur doit simplement sortir son canevas de ce client, le mettant au diapason de ce qui a été dessiné.

Tout conseil sur la mise en œuvre - spécifique ou philosophique - est apprécié.

Merci!

Answer 1

Une société pour laquelle je travaille a implémenté une application de tableau blanc avec node.js (mais n'a pas utilisé node-canvas) et socket.io. Malheureusement, je ne peux pas vous donner de code ou même un site web car il n'a pas été publié.

Votre implémentation semble très similaire. Les clients se connectent à notre serveur et mettent à jour le serveur à chaque fois que le tableau est dessiné (données JSON avec coordonnées (x, y)) via socket.io. Le serveur met ensuite à jour le reste des clients et conserve une copie de toutes les coordonnées (x, y) afin que les nouveaux clients qui se joignent puissent voir ce qui a déjà été dessiné.

Bonne chance avec votre application. J'ai beaucoup programmé avec node.js ces derniers temps et je l'adore.

Answer 2

J'ai écrit http://draw.2x.io, qui utilise node-canvas (anciennement node-cairo, que j'ai écrit moi-même) avec socket.io.

La façon dont j'ai conçu mon application, le client fait essentiellement toute la génération de course à partir de l'entrée de l'utilisateur. Ceux-ci sont à leur tour traités par une abstraction de toile, qui supporte un sous-ensemble d'opérations et de paramètres que j'ai définis moi-même. Si cette couche accepte l'entrée produite par les modules de peinture, elle est également envoyée via socket.io au serveur.

Sur le serveur, j'ai le même type de couche de recouvrement toile-noeud. Cela va donc répliquer l'entrée de l'utilisateur en mémoire, ce qui permettra éventuellement d'envoyer une image d'état à de nouveaux clients. Après cela, les traits seront - en attente de la validation des paramètres/du contexte par l'application serveur - publiés sur d'autres clients connectés, ce qui répétera la même procédure que ci-dessus.

Answer 3

est ici un tutoriel de tableau blanc multiutilisateur écrit en javascript/html5, toutes les sources disponibles: http://www.unionplatform.com/?page_id=2762

il est le nœud pas sur le côté serveur, mais le code côté client doit toujours être utile si vous voulez adapter à un nœud de backend.