Questions fréquentes

Pourquoi écrire MyDMAM en Java ?

Pour des raisons historiques et personnelles, et parce que je disposais déjà d’une base de code, j’ai choisi un environnement full Java. Ni php, ni Ruby, ni Python ne m’on convaincu suffisamment pour un tel projet. La découverte de Play! Framework m’a confirmé dans mes choix.

Pourquoi ne pas utiliser une base de donnée SQL classique comme MySQL MariaDB ou PostgreSQL ?

Les obligations de schémas, les problématiques de fragmentation des tables, les besoins de TTL sur les entrés, et les lenteurs avec les requêtes multi-tables m’ont poussé à explorer d’autres paradigmes.

Pourquoi deux bases de données différentes ?

Cassandra et ElasticSearch sont très différentes, n’ont pas le même but, ne s’utilisent pas de la même façon, mais sont totalement complémentaires. Cassandra pour récupérer et envoyer très rapidement  des ensembles clé/Colonnes/valeurs, et ElasticSearch pour la recherche/indexation et le stockage de données structurés.

Pourquoi avoir créé BrokerNG et ne pas utiliser le système de tâches déjà existant dans Play ?

MyDMAM est n’est pas centré sur Play, il a son propre centre nerveux (AppManager), c’est le vrai centre nerveux du système. Play est là pour rajouter une interface web à MyDMAM. Les fonctionnalités de tâches planifiées sont intéressantes mais trop limitées : si j’ai besoin d’écouter sur un socket un flux de donnés, c’est pas envisageable de le faire proprement avec Play ; ce n’est pas fait pour. De même, pour la moindre activité de taches, il aurai fallu a chaque fois démarrer le moteur de Play, son serveur web, la compilation des templates…

Pourquoi réinventer un Task Queue ?

J’ai préféré développer un système de gestion de tâche parce que je ne voulais pas rajouter un serveur de plus dans les dépendances, je voulais quelque chose de décentralisé (sans point central) et précis sans que sa soit trop complexe. J’ai rebondi sur l’opportunité des fonctions de lock sur une column familly avec Astyanax. Ce n’est pas forcément la meilleure approche, mais elle a le bon gout d’être très stable.

Pourquoi avoir ré-développé quelque chose de zéro et non pas avoir repris un code libre déjà existant ?

J’avais des impératifs de Java, de scalabilité, de NoSQL… Bref, besoin de quelque chose de nouveau. Et pas envie de me greffer sur un gros système pas forcément adapté et fabriquer une usine à Gaz (non, ce n’est pas le cas).

Pourquoi n’être pas passé sur Play! 2 ?

La nouvelle version de Play se concentre sur Scala et abandonne Groovy. J’ai commencé MyDMAM avec Play1 et la charge de travail pour passer sur Play2 ne se justifie pas encore compte tenu que Play1 me suffit largement. Et puis Play est là surtout pour apporter une interface graphique à MyDMAM, pas plus. Et il est encore maintenu.

Pourquoi avoir réinventé un nouveau système configuration via YAML ?

Configuration est une surcouche à un accès à des fichiers YAML (avec une mise en cache). Pas plus.