Salut, je voullais savoir si on pouvait passer en websocket pour les chats, ce serait plus fluide et en temps réelle, on peut utiliser C#, sur un server moyen, et il se chargerait de relayer et enregistrer les chats sur les differentes DB (ou sur la DB).
C'est juste une idée hein

Salut,

Oui ce serait possible, je l'ai d'ailleurs déjà fait sur d'autres projets en NodeJs. Par contre ce ne sera pas sur la version 3, qui en mode maintenance.

Je travaille sur la version 4 (date de sortie encore inconnue), qui est une ré-écriture complète du code. Un chat avec des websockets est prévu, mais plutôt en Golang pour des questions de performances et pour ne pas multiplier les langages présent sur la plateforme (il y en a déjà dans le backend, pour le monitoring et des api internes). 

Tu as raison, Go permet le multithreading d'une façon assez simple apparement, mais bon je t'avoue que c'est pas trop ma tasse de thé, mais pour le reste, Go est pas mal, facile a utiliser, et j'aime bien le concepte de "Go Get !" lol

Tu as fait des daemons en go pour le monitoring ?

 

Le monitoring interne des workers est en Go. L'idée est de pouvoir exposer aux modérateurs l'état des workers, pour leur donner quelques informations au cas où le site commence à se comporter bizarrement (dans le cas où tous les workers se seraient figés sur une tâche buggée par exemple). 

J'ai donc un petit serveur web Golang qui lit les métriques des workers et les expose sur une API Json. Api qui est ensuite exposée uniquement en interne et qui peut être interrogée par le backend de l'espace d'admin pour afficher ces métriques dans l'espace d'admin.

Puré, enfin in dev qui sait ce qu'il fait
En générale j'ajoute toujours des workers partout, c'est pas forcément évident, mais le résultat est simplement magnifique et puissant.

Parcontre, tu gére comment les write ? parceque le parallelisme en générale c'est un probleme a ce niveau.

Pardon pour le délai de réponse, je n'avaias pas vu ton message (caché dans les derniers sujets par un autre).

Pour le moment le parallélisme est un peu plus théorique que pratique, il y a différents points que je n'ai pas réglé car je suis toujours en developpement (mais c'est une question d'une poignée heure de travail).
Pour la base de donnée, je fait encore des select sans limites sur le nombre d'entités, donc il y a clairement un risque de modification en parallèle. Lorsque ça sera réglé, le mécanisme de transactions de l'ORM fera le reste pour éviter les modifications sur une entité par plusieurs workers.
Pour les tâches de type cron, un système de lock via Redis. Je pense qu'il y a moyen d'améliorer ça, mais ça marche pour le moment.