Petite mise à jour, je suis un peu revenu en arrière sur la façon dont je traite les choses. J'ai gardé mon système de commandes, mais au lieu d'aller taper dans la base de données pour charger la partie en cours et la mettre à jour, les commandes sont envoyées à un processus qui contient l'état de la partie et le met à jour.
C'est beaucoup plus simple puisque je ne stocke pas la partie en base de données. À la place, je peux éventuellement stocker l'état courant dans un fichier. Je ne le fais pour le moment que lors de la création de la partie, afin de pouvoir recharger ma page et que la partie existe quand j'éteins le serveur. Mais quand le code sera stable, je devrais alors décider si je sauve la partie à chaque modification ou jamais.
Ça rend mon code actuel beaucoup plus simple puisque je n'ai plus besoin de la partie qui gérait les accès concurrents à une même entité en base de données, mon processus de partie prend chaque commande une par une naturellement.
Les données d'une partie ne sont pas simples à stocker en base puisque composées de plusieurs objets imbriqués. Si je les stocke en base, à terme je pense que je sérialiserait tout dans un seul champ de type JSON.
J'ai trop tendance à direct partir dans des trucs complexes, écrire des semi-librairies, alors que des outils simples et efficaces sont à disposition.
Après je n'ai pas l'expérience d'une mise en production et d'une longue durée de vie qui requiert de continuer de gérer les anciens événements. Peut-être que c'est chiant. :p
Au taf on utilise pas mal docket et gitlab, du coup j'ai pu mettre en place toute une pipeline de mise en prod via push sur origin master qui déclenche une release mix, qui ensuite crée un container docker avec juste la release et ERTS, et qui pull ça depuis une sandbox public cloud OVH à 3€/mois !
C'est très agréable de pouvoir mettre en prod Phoenix de cette manière avec un simple git push et le container docker est tout petit, genre 20 Mo.