Mettre en place une sauvegarde des données de son application Bubble vers une base Airtable sans uniquement avec des fonctions natives de Bubble.
Table des matières
- Il ne faut pas mettre tous ses œufs dans le même panier
- Sauvegarde locale ou sauvegarde en SaaS
- Bubble ❤️ Airtable
- Mise en place de la sauvegarde
- 1- Préparation de la base Airtable et intégration dans Bubble
- 2- Backend API Workflows
- Bubble en frontend et Airtable en backend ?
Il ne faut pas mettre tous ses œufs dans le même panier
Une question qui se pose souvent avec l’utilisation des solutions No-Code (et pour les services en SaaS de manière générale) est celle de la localisation et la sécurité des données. La question est d’autant plus légitime lorsque l’on conseille à un client de remplacer ses fichiers dispersés par une application pour gagner en efficacité.
“Qu’est-ce que je deviens si la plateforme que vous me proposez est en panne ?”
Aucun service en ligne ne peut garantir une disponibilité à 100%. Il faut cependant relativiser le risque : une entreprise qui travaille en mode “fichiers” est également sujette à des problèmes techniques, voire une perte définitive de données (défaillance d’un poste ou d’un NAS par exemple).
Une plateforme SaaS sérieuse aura une réelle politique de sauvegarde sur plusieurs sites et le risque de perte de données par la plateforme est très faible.
Dans les deux cas de figure, une erreur humaine est possible et la mise en place de sauvegardes sous différentes formes est pertinente.
En conclusion, il ne faut pas tomber dans la paranoïa au risque de s’interdire beaucoup de solutions innovantes et efficaces, tout en pensant à l’adage “ne pas mettre tous ses œufs dans le même panier”, et puisque l’on parle de données, il est permis de dire “il faut copier ses œufs dans plusieurs paniers”.
Sauvegarde locale ou sauvegarde en SaaS
Une solution simple est de mettre en place un processus de sauvegarde récurrent en mode fichiers (Excel, CSV, etc.). Cela a un côté rassurant, car c’est facile à conceptualiser et on peut facilement voir la donnée sauvegardée.
En revanche, une telle sauvegarde est souvent difficile à utiliser dans l’urgence puisque l’on perd le côté fonctionnel et relationnel de l’application. En effet, la donnée d’une application est éclatée vers de nombreuses tables liées les unes aux autres et recréer manuellement ces relations pour rechercher une information peut s’avérer fastidieux (ceux à qui “RECHERCHEV” dit quelque chose comprendront).
Une alternative est donc de sauvegarder la donnée vers une autre application plus exploitable. Idéalement une base de donnée user-friendly, modulaire, flexible, dont l’interface peut facilement se paramétrer… en d’autres termes Airtable.
Bubble ❤️ Airtable
Bubble dispose d’un plugin “officiel” (c'est-à-dire développé par l’équipe Bubble et non un plugin tiers) pour se connecter à Airtable.
Son utilisation est assez simple, il suffit de renseigner sa clé API Airtable pour avoir accès à sa liste de bases de tables et choisir ainsi les table Airtable que l’on souhaite rendre disponible dans l’application Bubble.
Une fois que l’on a ajouté des tables Airtable, on peut utiliser la donnée dans les éléments Bubble et dans les Workflows, presque comme si l’on utilisait directement une table de donnée Bubble.
Mise en place de la sauvegarde
La mise en place de la sauvegarde s’effectue en deux étapes.
1- Préparation de la base Airtable et intégration dans Bubble
Dans un premier temps, il faut créer une base Airtable alignée sur son modèle de donnée Bubble (une table Airtable pour chaque table Bubble, avec un nommage et typage des champs à l’identique).
- Dans Airtable on crée un champ “Categorie” de type
link to another record(Catégorie) - On crée également un champ “Categorie_id” destiné à recevoir l’identifiant unique Bubble
- On met en place une “Automation” dans Airtable pour créer automatiquement les liaisons à partir de “Categorie_id” (En pratique, j’ai même deux “Automations” : une pour la création de record et une pour la mise à jour).
Une fois que l’on a créé toutes ses tables, on les ajoute dans l’application Bubble grâce au plugin Airtable.
2- Backend API Workflows
Au préalable, il faudra créer sur chaque table un champ date “DateSync” destiné à recevoir la date de sauvegarde Airtable pour un élément donné (ce champ doit être sur les tables Bubble et Airtable). Il permettra notamment de mettre en place un Workflow récursif, dans lequel on a besoin de savoir quelle donnée a été sauvegardée et quelle donnée reste à sauvegarder.
Détail du Workflow (pour la table “Valeur”)
Airtable limite l’utilisation de son API à 5 requêtes par seconde (source). Si on dépasse ce seuil, Airtable va passer en mode “dégrader” en augmentant artificiellement le temps de réponse de son API, ce qui peut la rendre beaucoup trop lente pour être exploitable. En pratique, j’ai constaté que :
- On peut dépasser temporairement la limite (plusieurs minutes) sans que Airtable passe en mode dégradé. En revanche, une fois en mode dégradé, il faut faire une longue pause pour retrouver le mode nominal.
- Si on charge l’API trop longtemps, même en respectant la limite, Airtable finit par passer en mode dégradé.
Pour tenir compte de ces observations, je prévois dans mon processus de sauvegarde une pause de 30 min après 500 records sauvegardés.
On isole un élément à sauvegarder. C’est soit l’ID passé en paramètre, soit on se base sur DateSync pour retrouver les éléments qui n’ont pas été sauvegardé récemment.
On relance un appel au Workflow. Comme on a déjà mis à jour DateSync, on ne passera pas plusieurs fois sur le même item. Si pas de valeur en Step 1, on brise la chaine. Si le compteur dépasse 500, on fait une pause (voir step 3).
Si le compteur dépasse 500, on fait une pause de 30 minute pour ne pas saturer l’API Airtable.
On met à jour le record correspondant dans Airtable.
Si le record n’existe pas dans Airtable, on le crée.
Ensuite, il suffit de planifier les sauvegarde pour chaque table, en utilisant le “scheduler” Bubble ou un service externe comme Make.
Puisque c’est Airtable qui reconstruira les relations, il faut réfléchir à l’ordre de sauvegarde de ses tables en fonction de leurs relations (d’abord table “mère”, puis tables “filles” avec un “automation” Airtable pour reconstruire la relation “fille→mère”)
Bubble en frontend et Airtable en backend ?
Grace au plugin Airtable on peut même développer une application Bubble qui utiliserait Airtable comme base de donnée plutôt que la base de donnée interne Bubble. Cette solution est très limitée en pratique, mais peut être intéressante dans certains cas.
Avantages
- Airtable est beaucoup plus efficace que l’interface Bubble pour éditer et consulter la donnée.
- Airtable apporte les “automation” et les “formulas”
- On peut utiliser un compte Bubble gratuit et dépasser les 200 enregistrements puisque la donnée est dans Airtable 😁
Inconvénients
- Quelques limitations dans les workflows par rapport aux tables de donnée Bubble
- Airtable limite son API à 5 requêtes par seconde, ce qui rend la solution inutilisable passé un certain volume. Un workflow simple génère facilement 4-5 requêtes (requête, sous-requête, modification d’une valeur…)
- Bien plus lent
En conclusion, construire une application sur la base Bubble Frontend / Airtable Backend risque d’être inadapté sur le long terme. En revanche, Bubble peut être un complément intéressant pour enrichir un outil métier basé sur Airtable car il peut permettre assez rapidement de construire des pages plus évoluées que les Interfaces Airtable.
