Cette base de données est en feu…

Permettez-moi de vous raconter une histoire technique.

Il y a de nombreuses années, j'ai développé une application avec des fonctionnalités de collaboration intégrées. C'était une pile expérimentale pratique, exploitant pleinement le potentiel du premier React et de CouchDB. Elle synchronisait les données en temps réel via JSON. OT. Elle était utilisée pour le travail interne de l'entreprise, mais son applicabilité et son potentiel dans d'autres domaines étaient évidents.

En essayant de vendre cette technologie à des clients potentiels, nous avons rencontré un obstacle inattendu. Dans la vidéo de démonstration, notre technologie avait l'air et fonctionnait parfaitement, il n'y avait aucun problème. La vidéo montrait exactement comment cela fonctionne, sans aucune simulation. Nous avons conçu et codé un scénario d'application réaliste pour le programme.


En réalité, cela a été le problème. Notre démo fonctionnait exactement comme l'imitation de l'utilisation de leurs applications par tous les autres. Plus précisément, les informations étaient transmises instantanément de A à B, même s'il s'agissait de gros fichiers multimédias. Après connexion, chaque utilisateur voyait de nouvelles entrées. Grâce à l'application, différents utilisateurs pouvaient collaborer clairement sur les mêmes projets, même en cas d'interruption de la connexion Internet quelque part dans un village. Cela était implicitement sous-entendu dans n'importe quelle vidéo découpée dans After Effects sur le produit.

Bien que tout le monde sache à quoi sert le bouton de rafraîchissement, personne ne comprenait vraiment que les applications Web, que l'on nous demande de créer, sont souvent sujettes à leurs limitations. Et que si elles ne sont plus nécessaires, l'expérience utilisateur sera totalement différente. En général, ils remarquaient qu'il était possible de « discuter », en laissant des notes à leurs interlocuteurs, se posant donc la question de la différence avec, par exemple, Slack. Ouf !

Le design des synchronisations quotidiennes

Si vous avez déjà de l'expérience dans le développement de logiciels, vous devez trouver frustrant de devoir se rappeler que la plupart des gens ne peuvent pas simplement regarder une image de l'interface et comprendre ce qu'elle fera lors de l'interaction avec elle. Sans parler de ce qui se passe à l'intérieur du programme lui-même. Savoir ce qui peut doit se produire est en grande partie le résultat de la connaissance de ce qui ne peut pas se produire et ce qui ne doit pas se produire. Cela nécessite modèle mental non seulement ce que fait le logiciel, mais aussi la façon dont ses différentes parties sont alignées et communiquent entre elles.

Un exemple classique de cela est un utilisateur regardant pendant vingt minutes spinner.gif, se demandant quand le travail prendra enfin fin. Le développeur comprendrait que le processus est probablement gelé, et que le GIF ne disparaîtra jamais de l'écran. Cette animation simule l'exécution d'une tâche, mais n'est pas liée à son état. Dans de tels cas, certains techniciens aiment lever les yeux au ciel, s'interrogeant sur le degré d'illusion des utilisateurs. Mais remarquez, qui parmi eux pointe sur l'horloge tournante et dit qu'elle est en réalité immobile ?

C'est là que réside la valeur du temps réel. De nos jours, les bases de données en temps réel sont encore très peu utilisées, et beaucoup s'en méfient. La plupart de ces bases de données tendent vers un style NoSQL, ce qui amène souvent à utiliser des solutions basées sur Mongo, qu'il vaut mieux oublier. Pour moi, cela signifie le confort de travailler avec CouchDB, ainsi que l'exploration de la conception de structures capables d'être remplies de données par autre chose qu'un bureaucrate. Je pense que je gère mon temps de manière plus optimale.

Mais le véritable sujet de ce post est ce que j'utilise aujourd'hui. Non pas par choix, mais en raison d'une politique d'entreprise appliquée de manière indifférente et aveugle. Par conséquent, je vais fournir une comparaison totalement honnête et impartiale de deux produits étroitement liés pour travailler avec des bases de données en temps réel de Google.

Les deux ont le mot Fire dans leur nom. L'un je me souviens avec tendresse. L'autre pour moi est un autre type de feu. Je ne me dépêche pas de dire leurs noms, car une fois que je le ferai, nous serons confrontés au premier grand problème : les noms.

Le premier s'appelle Firebase Real-Time Database, et le second — Firebase Cloud Firestore. Tous deux sont des produits de la suite Firebase de Google. Leurs API s'appellent, respectivement, firebase.database(…) et firebase.firestore(…).

Cela s'est produit parce que Real-Time Database était simplement l'original Firebase avant son acquisition par Google en 2014. Ensuite, chez Google, ils ont décidé de créer un produit parallèle sous la forme d'une copie de Firebase basé sur les big data de l'entreprise, et l'ont nommé Firestore with a cloud. J'espère que vous ne vous êtes pas encore perdu. Si vous êtes perdu, ne vous inquiétez pas, j'ai moi-même réécrit cette partie de l'article dix fois.

Parce qu'il faut préciser Firebase en ce qui concerne Firebase, et Firestore en ce qui concerne Firebase, du moins pour que vous soyez compris il y a quelques années sur Stack Overflow.

S'il existait un prix pour le pire nommage de produits logiciels, ce cas serait certainement un des prétendants. La distance de Hamming entre ces noms est si faible qu'elle perturbe même des ingénieurs expérimentés dont les doigts tapent un nom alors que leur tête pense à un autre. Ce sont des plans qui ont échoué avec fracas, conçus avec les meilleures intentions ; ils ont réalisé la prophétie selon laquelle la base de données serait en feu. Et je ne rigole pas. La personne qui a conçu un tel schéma de nommage a été à l'origine de sang, de sueur et de larmes.

Une victoire à la Pyrrhus

On pourrait penser que Firestore est le remplacement de Firebase, son descendant de nouvelle génération, mais ce serait une erreur. Firestore n'est absolument pas destiné à remplacer Firebase. On dirait que quelqu'un a retiré tout ce qui était intéressant, et la majeure partie du reste a été compliquée de différentes manières.

Cependant, un coup d'œil rapide aux deux produits peut vous induire en erreur : ils semblent faire la même chose, via principalement des API identiques et même dans la même session de base de données. Les différences sont peu visibles et ne se dévoilent qu'à travers une étude comparative minutieuse de la documentation détaillée. Ou lorsque vous essayez de porter un code qui fonctionne parfaitement sur Firebase pour qu'il fonctionne avec Firestore. Même alors, vous découvrirez que l'interface de la base de données s'enflamme dès que vous essayez de faire glisser la souris en temps réel. Je le répète, je ne rigole pas.

Le client Firebase est poli dans le sens où il met en mémoire tampon les modifications et effectue automatiquement des tentatives de mise à jour, en donnant la priorité à la dernière opération d'écriture. Cependant, Firestore a une limite de 1 opération d'écriture par document par utilisateur par seconde, et cette limite est imposée par le serveur. En travaillant avec, vous devez vous-même trouver un moyen de contourner cela et mettre en œuvre une limitation de fréquence des mises à jour, même lorsque vous essayez simplement de créer votre application. Autrement dit, Firestore est une base de données en temps réel sans client en temps réel, qui se camoufle en tant que telle grâce à l'API.

C'est ici que nous commençons à voir les premiers signes de la raison d'être de Firestore. Peut-être que je me trompe, mais je soupçonne que quelqu'un en haut de la direction de Google a regardé Firebase après son acquisition et a simplement dit : « Non, mon Dieu, non. C'est inacceptable. Pas sous ma direction ».

Il est sorti de ses appartements et a proclamé :

« Un gros document JSON ? Non. Vous devez diviser les données en documents séparés, chacun d'une taille maximale d'un mégaoctet ».

Il semble qu'une telle restriction ne survivra pas au premier affrontement avec une base d'utilisateurs suffisamment motivée. Vous le savez. Au travail, par exemple, nous avons plus de mille cinq cents présentations, et c'est tout à fait normal.

Avec une telle restriction, vous serez contraint d'accepter le fait qu'un « document » dans la base de données ne ressemblera à aucun objet que l'utilisateur pourrait désigner comme document.

« Des tableaux de tableaux, qui peuvent récursivement contenir d'autres éléments ? Non. Les tableaux ne contiendront que des objets ou des nombres de longueur fixe, comme le veut le Seigneur ».

Donc, si vous espériez inclure votre GeoJSON dans Firestore, vous découvrirez que c'est impossible. Rien de non unidimensionnel n'est autorisé. J'espère que vous aimez Base64 et/ou JSON à l'intérieur de JSON.

« Importer et exporter JSON par HTTP, outils en ligne de commande ou tableau de bord d'administration ? Non. Vous ne pourrez qu'exporter et importer des données dans Google Cloud Storage. Ainsi, ça s'appelle maintenant. Et quand je dis « vous », je m'adresse uniquement à ceux qui ont les droits de Project Owner. Tous les autres peuvent aller créer des tickets. »

Comme vous pouvez le voir, le modèle de données FireBase est facile à décrire. Il contient un énorme document JSON, liant des clés JSON à des chemins d'URL. Si vous écrivez avec HTTP PUT dans / FireBase le suivant :

{
  "hello": "world"
}

Alors GET /hello renverra "world". En gros, cela fonctionne exactement comme vous vous y attendez. La collection d'objets FireBase /my-collection/:id équivaut à un dictionnaire JSON {"my-collection": {...}} à la racine, dont le contenu est accessible à /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

Cela fonctionne très bien si chaque insertion a un ID sans collision, pour ce à quoi le système a une solution intégrée.

En d'autres termes, la base de données est 100 % compatible avec JSON (*) et fonctionne parfaitement avec HTTP, par exemple avec CouchDB. Mais principalement, vous l'utilisez via une API en temps réel, qui abstrait les websockets, l'autorisation et les abonnements. Le panneau d'administration offre les deux options, permettant d'éditer en temps réel et d'importer/exporter du JSON. Si vous suivez cela dans votre code, vous serez surpris de voir combien de code spécialisé disparaîtra lorsque vous comprendrez que patch et diff JSON permettent de résoudre 90 % des tâches répétitives liées à la gestion d'état persistant.

Le modèle de données Firestore ressemble à JSON, mais se différencie sur certains aspects critiques. J'ai déjà mentionné l'absence de tableaux à l'intérieur de tableaux. Le principe des sous-collections est qu'elles sont des concepts de premier ordre, distincts du document JSON qui les contient. Comme il n'existe pas de sérialisation prête à l'emploi pour cela, l'obtention et l'écriture de données nécessitent un chemin d'exécution de code spécialisé. Pour gérer vos propres collections, vous devez écrire vos propres scripts et outils. Le panneau d'administration ne permet d'apporter que de petites modifications, champ par champ, et n'a pas de fonctionnalités d'import/export.

Ils ont pris une base de données NoSQL en temps réel et l'ont transformée en une solution SQL lente avec auto-fusion et une colonne distincte non-JSON. Un peu comme GraftQL.

Java chaud

Si Firestore devait devenir plus fiable et évolutif, l'ironie est que le développeur moyen obtiendra une solution moins fiable que s'il choisissait FireBase « clé en main ». Le logiciel dont a besoin le Administrateur de Base de Données Grognon nécessite un niveau d'efforts et un calibre de spécialistes qui sont simplement irréalistes pour le marché où un bon produit est censé être présent. C'est comme si le Canvas HTML5 n'était pas du tout un remplacement de Flash, s'il n'existe pas d'outils de développement et de lecteurs. De plus, Firestore est embourbée dans la quête de pureté des données et de validation stérile, ce qui ne correspond tout simplement pas à la manière dont un utilisateur commercial moyen aime travailler: car pour lui, rien n'est obligatoire, car jusqu'à la fin, tout n'est qu'un brouillon.

Le principal inconvénient de FireBase est que le client a été créé plusieurs années avant son calendrier, bien avant que la plupart des développeurs web n'aient connaissance de l'immuabilité. En conséquence, FireBase suppose que vous allez modifier les données et ne tire donc pas parti de l'immuabilité fournie par l'utilisateur. De plus, il ne réutilise pas les données dans les instantanés transmis à l'utilisateur, rendant ainsi l'exécution des différences beaucoup plus difficile. Pour de gros documents, son mécanisme de transaction basé sur des différences modifiables est simplement inadéquat. Les gars, nous avons déjà WeakMap en JavaScript. C'est pratique.

Si vous donnez aux données la forme appropriée et que vous ne rendez pas les arbres trop volumineux, vous pouvez contourner ce problème. Mais je me demande si FireBase serait beaucoup plus intéressant si les développeurs avaient publié une véritable bonne API client exploitant l'immuabilité, associée à de solides conseils pratiques sur la structure des bases de données. Au lieu de cela, ils semblent avoir essayé de réparer ce qui n'est pas cassé, et cela a empiré.

Je ne connais pas toute la logique qui a sous-tendu la création de Firestore. Réfléchir aux motivations se trouvant à l'intérieur d'une boîte noire fait aussi partie du divertissement. Une telle opposition entre deux bases de données extrêmement similaires, mais incomparables, est assez rare. C'est comme si quelqu'un avait pensé : «Firebase est simplement une fonction que nous pouvons émuler dans Google Cloud», mais sans encore avoir découvert le concept de définition des exigences du monde réel ou de création de solutions utiles répondant à toutes ces exigences. «Laissez cela aux développeurs. Rendre simplement l'interface utilisateur attrayante… Peut-on ajouter un peu plus de flair ?»

Je comprends quelques notions sur les structures de données. Je vois clairement que le concept de «tout dans un grand arbre JSON» est une tentative d'abstraire de la base de données toute sensation de structure à grande échelle. S'attendre à ce que le logiciel gère simplement n'importe quel fractal douteux de structure de données est tout simplement insensé. Je n'ai même pas besoin d'imaginer à quel point cela peut être mauvais, j'ai effectué des audits de code rigoureux et j'ai vu des choses auxquelles vous, les gens, n'avez même pas pensé.. Mais je sais aussi à quoi ressemblent de bonnes structures, comment les utiliser et et pourquoi il est nécessaire de le faire.Je peux imaginer un monde où Firestore semblerait tout à fait logique, et où les personnes qui l'ont créée penseraient avoir fait du bon travail. Mais nous ne vivons pas dans ce monde.

Le support de la construction de requêtes dans FireBase est médiocre selon n'importe quelle norme, il est pratiquement inexistant. Il nécessite clairement des améliorations, ou au moins une révision. Mais Firestore n'est pas beaucoup mieux, car il est limité par les mêmes index unidimensionnels que l'on trouve dans un simple SQL. Si vous avez besoin de requêtes que les gens effectuent avec des données chaotiques, vous aurez besoin d'une recherche textuelle complète, de filtres sur plusieurs plages et d'un ordre défini par l'utilisateur aléatoirement. En examinant de près les fonctions du simple SQL, elles sont en soi trop limitées. De plus, les seules requêtes SQL que les gens peuvent exécuter en production sont des requêtes rapides. Vous aurez besoin d'une solution spécialisée pour l'indexation avec des structures de données réfléchies. Pour tout le reste, il doit au moins y avoir un map-reduce incrémental ou quelque chose de similaire.

Si vous recherchez des informations à ce sujet dans la documentation de Google, espérons que cela vous orientera vers quelque chose comme BigTable et BigQuery. Cependant, toutes ces solutions s'accompagnent d'un volume de jargon dense lié aux ventes d'entreprise, si bien que vous revenez rapidement en arrière et recommencez à chercher autre chose.

La dernière chose dont vous avez besoin dans une base de données en temps réel, c'est quelque chose créé par des humains et pour des humains, fonctionnant à l'échelle des salaires pour des cadres.

(*) C'est une blague, il n'existe pas de concept tel que compatibilité JSON à 100%.

En tant que publicité

Vous cherchez — serveur dédié virtuel. un serveur pour le développement et l'hébergement de projets ? Vous êtes exactement notre client 🙂 La tarification journalière des serveurs de différentes configurations, anti-DDoS et licences Windows sont déjà incluses dans le prix.

Source : habr.com