Le compagnon Alkemy, de Parse à Django

Suite à l’annonce de l’arrêt du service Parse qui me sert jusqu’ici à héberger les données des applications Brothers in Games, j’ai commencé à repenser la manière dont je gère ces données. Cela m’a conduit à avoir un référentiel unique indépendant des services tiers (Parse ou autres). Je vais ici vous illustrer ce service destiné à l’app compagnon Alkemy. Pour ceux qui ne connaissent pas ce jeu de figurines, je vous invite à consulter les autres articles traitant d’Alkemy.

Bonne nouvelle également, ce service, je le publie en Open Source.

Pour commencer, je vais rappeler mes besoins liés à l’app Compagnon Alkemy. Cette app permet de consulter les données du jeu Alkemy : les profils des figurines, leurs compétences, les formules… Ces données sont hébergées en ligne afin que les utilisateurs puissent avoir des données à jour sans nécessiter une mise à jour de l’app.

Parse satisfaisait complètement à ce besoin. Mais qui dit mettre à jour les données dit aussi proposer une interface pour l’édition. Là, Parse n’est pas terrible, son affichage par tableau rend l’édition de tout ce qui au delà du premier niveau impossible. Firebase, qui est l’alternative la plus évidente n’est pas mieux. Bien entendu, si je me tourne vers le développement de mon service, il faudra tout faire.

Unchained efficiency

Et bien qu’à cela ne tienne, et autant utiliser les outils les plus efficaces. J’ai donc fini par retourner vers ce bon vieux Django. Je ne vais pas vous présenter Django ici, mais je vais le résumer comme le framework web Python. Ce qui m’a surtout intéressé avec Django, c’est la rapidité et facilité avec laquelle on peut créer un modèle de données qui peut être persisté en base ainsi que l’interface d’administration qui va avec. Celle-ci est générée automatiquement et est presque fonctionnelle.

Pour ceux qui sont intéressés par le code, il est disponible sur Github. Même si vous n’avez pas de connaissance en Python et Django, vous pourrez je pense comprendre le modèle de données dans le module models. Un seul autre module contient du code, c’est le module admin. Ce module décrit l’organisation des formulaires générés par Django.

Et oui, ces 300 lignes commentaires compris suffisent à décrire les données du jeu, à les sauvegarder dans une base, à les consulter et les afficher sous forme de formulaires un peu spartiates mais fonctionnels.

Comment intégrer l’app Alkemy à votre projet Django ?

Pour cette partie, je pars du principe que vous avez des bases en développement Python. Vous connaissez également les outils de la boîte à outils Python.

Il faut donc commencer par créer un virtualenv pour votre projet Django. Ce virtualenv sera actif à sa création. Je vais y ajouter Django qui est la seule dépendance nécessaire puis le chemin vers les sources Alkemy (changez évidemment cette valeur par votre chemin).

mkvirtualenv figAppEnv
pip install django
add2virtualenv /home/user/opensource/BiG-Alkemy-django

Voilà, vous pouvez maintenant créer votre projet dans votre arborescence de travail et ajouter Alkemy à la liste des apps. La dernière ligne ajoute au PYTHONPATH de votre virtualenv la ressource Alkemy.

Dans la version actuelle, il n’y a aucune interface publique. Vous n’avez donc aucun URL à configurer. La gestion des profils est réalisée dans l’admin. Vous pouvez bien entendu étendre cette app pour ajouter vos propres interfaces.

Ce qu’il n’y a pas dans les sources Alkemy

Pour commencer, il n’y a aucune donnée de jeu… En tout cas, dans les sources à ce jour. Je ne possède pas de droits sur ces données et il faut donc que je vois avec Alchemist Miniatures.

Ensuite, j’ai écris cette app pour pouvoir gérer correctement les données. Je n’ai à l’heure actuelle pas finalisé la migration de Parse, je n’ai donc pas de code d’export vers un autre service. J’ai cependant du code d’import des données de Parse vers cette app. Ce code ne fait pas parti de cette app. La raison principale est une raison d’architecture : le périmètre fonctionnel de l’app Alkemy est de gérer les données du jeu, pas à résoudre des problèmes techniques de gestion de ces données. Ainsi, tout ce qui est import, export ou synchronisation doit faire parti d’une autre app.

Si par contre je décide finalement que cette app exposera ces données sous forme d’interface ou de webservice, alors, ces vues feront bien parti de l’app. Mais pour l’instant, l’interface d’administration suffit. Il n’y a donc pas d’interfaces publique, mais il est tout à fait envisageable de proposer l’équivalent d’Architekt.

Évolution

En 300 lignes doc incluse, cette app permet de gérer les données du jeu Alkemy. Il va maintenant rester à les exposer aux utilisateurs. Si je m’oriente vers Firebase (ce qui est loin d’être certain), il suffit d’ajouter un service d’export des données. Celui-ci sera donc dans une app dédiée qui suivra l’historique des synchronisations. Les champs updatedAt permettant de n’exporter que les données mises à jour.

Si je m’oriente vers une interface web ou(/et) des webservices, ceux-ci auront leur place dans les vues (module views) de cette app.

Il n’y a plus qu’à faire…

De votre coté, si vous avez des propositions, retours ou questions, n’hésitez pas.