Un retour d'expérience sur le développement d'un jeu, 1 an et demi après.

Voici le retour:

Microservices vs. Monolithe n'est pas la question: dans tous les cas, votre soucis le plus immédiat est d’isoler les composants chacun derrière des interfaces publiques clairement définies. Avoir un binaire par tâche ou plusieurs dépend en réalité du nombre de personnes et d'équipes qui travaillent sur le projet.

À voir le projet gRPC afin de faire communiquer les différentes interfaces. Pourquoi gRPC ? Pour générer automatiquement le code d'un service lorsque celui-ci se content d'exposer des méthodes CRUD sur une simple entité dans une base de données SQL.
Qui finalement s'est révélé moins pratique à la longue lorsque les requêtes se sont complexifiées.

Contrairement au dicton qu'il ne faut pas réinventer la roue, certaines valent mieux être réinventée. Ici:

• l'ORM gorm par une bibliothèque plus bas niveau: sqlx
• testify remplacé par rien

Finalement, ce n'est pas une réinvention, mais un débarras de surcouche en complexité.

Le mantra d'E.W. Djikstra:

Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set?

la maîtrise du problème est beaucoup plus importante que la solution qu’on lui apporte

Concernant les tests: l'auteur recommande le TDD pour développer ce qui est utile uniquement.

Enfin il s'agit surtout de maîtriser le problème afin de parvenir à une excellente solution.