Le concept
L’idée c’était de pouvoir tracer des vélos équipés de boitiers qui signalent leur position via des réseaux bas débit (en l’occurence du Sigfox) dès que le vélo bouge. Le boitier intégrait pour cela un accéleromètre ce qui permettait d’envoyer la position GPS du vélo uniquement quand celui-ci bougeait vraiment.
Chaque propriétaire devait ainsi pouvoir se connecter sur un espace perso depuis lequel il était en mesure de voir ou se trouvait son vélo. L’appli était également pensée en mode “flotte”, pour les municipalités ou les loueurs de vélos par exemple pour leur permettre de suivre l’activité des différents vélos de leur parc avec un accent sur la possibilité de faire du geofencing, par exemple pour que les administrateurs de la flotte soient avertis sur le canal de leur choix quand un vélo entre/sort d’une zone.
La technique
Sous le capot, on retrouve Kuzzle (https://kuzzle.io), un backend développé par Kaliop qui se spécialise dans le traitement temps réel d’informations. Rapidement, c’est un wrapper devant un elasticsearch et un redis qui écrit en javascript/C qui permet de s’abonner à des opérations CRUD sur des documents indexés. Dans la même veine, on avait Deepstream (https://deepstream.io) ou encore RethinkDB (https://rethinkdb.com).
Petite note, à l’époque, Kuzzle était en version Beta. Depuis, et à ce jour (2021), j’ai pas suivi le fonctionnement de Kuzzle, qui m’a l’air d’avoir pas mal évolué, donc je parlerai de mon expérience d’alors ;-)
Le presta chargé de la partie hardware envoyait les events en provenance des vélos sur l’un de nos endpoints API. La payload d’un message sigfox étant limitée en taille, on récupère uniquement le nécessaire : identifiant du boitier, coordonnées GPS, état de la batterie et… de mémoire, c’était à peu près tout :-).
Quand ces events arrivent, on se charge de récupérer les zones que l’admin du vélo a défini sur une carte interactive : s’il entre dans une zone ou qu’il en sort, on publie des notifications (mail/SMS). Ici, c’est Kuzzle qui gère l’aspect Geofencing via des Geo Queries sous traitées à ES (https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-geo-shape-query.html).
On avait un worker qui s’abonnait à des événements de type entrée/sotie d’une zone pour envoyer les notifications. L’idée c’était de découpler le traitement du message pour rapidement répondre une 200 au presta et d’appliquer toutes les règles métier à appliquer juste après.
Démo et améliorations
Suite à une démo ou on s’était dit que ce serait une bonne idée d’avoir de vrais gens qui pédalent sur un vélo équipé du boitier pendant que tout le monde regarde un point bouger sur la carte de l’appli, j’ai commencé à bosser sur un simulateur de flotte de vélos, qui en réutilisant les APIs de l’appli nous permettait de simuler le comportement d’une flotte réaliste de vélos. La personne qui faisait la démo pouvait décider du nombre de vélos à simuler, dans quelle zone géographique.
L’idée de cette “meta-appli” était de simplifier un peu l’avant vente du poc en permettant de personnaliser des scénarios en fonction du client potentiel. Ainsi, quelqu’un de non tech pouvait littéralement programmer son scénario pour que le client final ait les moyens de se projeter avec cette appli.
Sous le capot, le démonstrateur ne faisait que générer X vélos, les créer dans la BDD de l’appli, puis venait poster autant d’évènements que nécessaire sur les APIs normalement destinées aux boitiers des vrais vélos. Un vélo pouvait: démarrer, se déplacer, s’arréter. A chaque fois que le simulateur décidait qu’un vélo se déplaçait, on recalcule aléatoirement les coordonnées GPS du vélo dans un rayon réaliste afin que le déplacement semble réaliste pour un humain.
Ce démonstrateur a très peu servi, mais j’ai beaucoup appris en le créant. C’était vraiment sympa de se dire qu’on pouvait tester son appli avec une autre appli, le tout en se basant exclusivement sur les APIs de la vrai appli !