Plan trimestriel #2 : le bilan

La séquence avril-mai-juin est terminée, le temps est passé très vite, mais je crois que j'ai réussi à faire ce que je voulais, c'est-à-dire défricher le terrain.

Les objectifs de cette période étaient pour rappel :

• d'évaluer la faisabilité de la synchronisation des données entre plusieurs installations de Joliebulle.

• d'évaluer la faisabilité d'une petite application web complémentaire : une fois que les données sont sur un serveur, on aurait tort de s'en priver.

J'ai fait mes devoirs, exploré plusieurs pistes, et voici comment la situation se présente.

Sur le plan technique

Au niveau technique, il y a 3 niveaux de problèmes à résoudre :

• la base de données qui va accueillir les données des utilisateurs

• l'application web qui va accéder à ces données

• Joliebulle 4

Et il y a 2 grosses difficultés.

1. La première, c'est la question de la synchronisation des données entre plusieurs installations de Joliebulle, car elles sont stockées par défaut localement, dans un format simple, et les instances de Joliebulle sont par défaut offline. Quand on commence à connecter certaines instances à des moments différents et à modifier les données, la synchronisation devient rapidement assez complexe.

   Il existe des solutions pour s'en sortir, par exemple une combinaison d'hybrid logical clocks et de CRDTs, mais le format actuel de stockage des données de Joliebulle, volontairement simpliste, n'est pas du tout adapté.

   L'alternative est une synchronisation plus ou moins manuelle, en laissant l'utilisateur décider de ce qu'il envoie et récupère du serveur. C'est simple, robuste, mais en tant qu'utilisateur je déteste, je pense que tout le monde déteste, et donc ça ne serait que temporaire.

2. La deuxième difficulté, c'est de trouver des technologies communes à la plateforme web et au logiciel de bureau, pour permettre aux deux projets de communiquer entre eux. Joliebulle 4 s'appuie déjà beaucoup sur des technologies du web ce qui facilite grandement les choses. Mais il y a quand même des contraintes, et je ne peux pas faire exactement ce que je veux.

Mais revenons à nos moutons.

Je vous parlais de la base de données.

Le principal pré-requis, c'est que nous avons besoin d'un service complètement géré.

Quand on est une petite équipe et a fortiori quand on est tout seul, c'est le seul moyen d'espérer maintenir un semblant de qualité de service. Maintenir soi même une base de données et tout l'environnement logiciel qui va avec, c'est un métier, des compétences, et une disponibilité sans faille. Compétent ou pas, si vous êtes en week-end quand le datacenter prend feu, vous l'avez dans le baba et vos utilisateurs également.

Les autres pré-requis en vrac :

• un truc pas trop exotique

• une communauté d'utilisateurs, un service mature et activement maintenu

• une bonne documentation

• SQL, noSQL, peu importe. Sur le papier une base orientée document correspond bien à la situation de Joliebulle, mais à notre échelle on peut faire la même chose avec du pur Sql, avec en bonus le relationnel quand on en a besoin. En fait, ce n'est pas un critère de sélection.

Un autre point que je souhaiterais vraiment déléguer, c'est l'authentification. C'est un point sensible, et je sais par expérience que c'est beaucoup de travail pour faire les choses comme il faut.

Au final, j'ai fait plusieurs essais.

Firebase

C'est le poids lourd du secteur, et une solution de confort. La plateforme offre une solution complète qui va de l'authentification à la base de données en passant par les mails transactionnels, on peut tout faire sans utiliser un autre service.

Les données sont stockées sous la forme d'un simple arbre JSON, sans schéma.

C'est déjà ce que fait Joliebulle 4, il y a donc une certaine facilité pour les échanges de données.

J'ai un peu plus de mal avec l'API, que je ne trouve pas très élégante ni agréable à l'usage, et peut-être pas très performante.

La maintenance à long terme pose question.

Un autre gros frein reste la dépendance à la plateforme, qui est entièrement propriétaire (et rachetée par Google en 2015).

C'est un point qui est à relativiser, il vaut mieux être dépendant d'une solution durable, avec une grosse communauté qui mobilise des acteurs importants, plutôt que de dépendre d'une obscure petite librairie open-source qui peut aussi être abandonnée du jour au lendemain.

J'ai fait un premier prototype de site avec Firebase, je suis impressionné par la vitesse de développement, je vous en parle plus bas.

Je suis moins impressionné par la documentation, qui est très complète, mais c'est sa seule qualité.

Les autres

J'ai fait d'autres essais de bases de données, et pour être honnête je n'ai pas fini.

Un truc à la mode en ce moment est d'utiliser une base de données type PostgreSql, et de venir ajouter une couche pour réaliser des requêtes type GraphQL (Hasura, Prisma) ou sur le même modèle que Firebase (Supabase).

J'ai testé, c'est sympa, il y a quand même des inquiétudes concernant la maturité de certaines librairies utilisées, l'intégration de l'authentification est parfois problématique, la multiplication des points de défaillance. A suivre.

Ce qui s'est passé ensuite

Je suis parti sur l'option Firebase, que j'ai commencé à intégrer dans Joliebulle. Comme je le disais plus haut, la synchronisation des données est un problème difficile. En l'état la version de dev de Joliebulle est capable d'authentifier un utilisateur, d'envoyer les données vers Firebase, et de récupérer les données, le tout plus ou moins manuellement.

Côté web, j'ai développé une petite application à base de Next.js. L'application permet de se logger, d'accéder à la liste de ses recettes hébergées sur Firebase, de gérer son compte utlisateur (changement de mot de passe, mdp oublié, etc).

Elle ne fait donc pas grand chose à ce stade, mais sur le principe il serait possible d'itérer tranquillement dessus.

Les bases du design sont là aussi, c'est bien, c'est un travail qui pourra être réutilisé dans tous les cas.

L'alternative

A ce stade, le point positif c'est que j'ai sous la main un résultat concret, limité mais qui fonctionne.

Le point négatif, c'est la vision à long terme. Telle qu'elle se présente, la fonctionnalité de synchronisation s'intègre mal au workflow de Joliebulle, et ne s'adressera qu'à une petite niche d'utilisateurs.

Après quelques semaines à travailler sur une application web, le sens des priorités change. Quel serait le résultat si on mettait de côté l'intégration dans Joliebulle 4 et la synchronisation des données ? Une petite application web minimaliste standalone qui accepterait simplement des fichiers jb4 pour l'interopérabilité ?

C'est une piste que j'ai maintenant envie de creuser.

La suite

Dans tous les cas, le plan trimestriel est clôturé.

Il est temps de passer à autre chose.

En fait, je vais continuer à explorer des pistes en lien avec les thématiques que nous avons abordées aujourd'hui, mais sans objectif de mise en production à court terme.

Je vous laisse là pour aujourd'hui, de mon côté je continue de travailler sur le projet, probablement de façon un peu plus décousue pendant la période estivale, et je publierai un nouveau plan trimestriel à la fin de l'été.