Laissez-moi vous raconter une histoire technique.
Il y a plusieurs années, je développais une application intégrant des fonctionnalités de collaboration. C'était une pile expérimentale pratique qui tirait parti du plein potentiel des premiers React et CouchDB. Il synchronisait les données sur JSON OT en temps réel . Il a été utilisé en interne dans l'entreprise, mais sa large 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 très bien, aucun problème. La vidéo a montré exactement comment cela fonctionne, et rien n'a été imité. Nous avons conçu et codé un scénario réaliste pour l'utilisation du programme.
En fait, c'est devenu le problème. Notre démo fonctionnait exactement comme tout le monde simulait le travail de leurs applications. Plus précisément, les informations étaient instantanément transférées de A à B, même s'il s'agissait de fichiers multimédias volumineux. Une fois connecté, chaque utilisateur a vu de nouvelles entrées. Grâce à l'application, différents utilisateurs pouvaient collaborer sur exactement les mêmes projets, même si la connexion Internet était interrompue quelque part dans le village. Cela est implicitement implicite dans toute vidéo de produit coupé dans After Effects.
Même si tout le monde savait à quoi servait le bouton Actualiser, personne n'avait compris que les applications Web qu'ils nous demandaient de créer étaient généralement soumises à leurs propres limites. Et que s'ils ne sont plus nécessaires, l'expérience utilisateur sera complètement différente. En gros, ils ont remarqué que vous pouviez "discuter" en laissant des notes aux interlocuteurs, ils se sont donc demandé en quoi cela différait, par exemple, de Slack. Uf-f-f!
Conception de synchronisation quotidienne
Si vous avez déjà de l'expérience dans le développement de logiciels, vous devez vous rappeler que la plupart des gens ne peuvent pas simplement regarder une image d'une interface et comprendre ce qu'elle fera en interagissant avec elle. Sans parler de ce qui se passe à l'intérieur du programme lui-même. Savoir ce qui peut arriver est en grande partie le résultat de savoir ce qui ne peut pas arriver et ce qui ne devrait pas arriver. Cela nécessite un modèle mental non seulement de ce que fait le logiciel, mais aussi de la façon dont ses différentes parties sont coordonnées et communiquent entre elles.
Un exemple classique de ceci est un utilisateur regardant spinner.gif pendant vingt minutesse demandant quand le travail se terminera enfin. Le développeur comprendrait que le processus est probablement figé et que le gif ne disparaîtra jamais de l'écran. Cette animation simule l'exécution du travail, mais n'est pas associée à son état. Dans des cas comme celui-ci, certains techniciens aiment rouler des yeux, s'émerveillant du degré de confusion des utilisateurs. Cependant, remarquez lequel d'entre eux indique l'horloge rotative et dit qu'ils sont en fait stationnaires?
C'est l'essence même de la valeur en temps réel. Les bases de données en temps réel sont encore très peu utilisées de nos jours, et beaucoup se méfient d'eux. La plupart de ces bases de données penchent activement vers le style NoSQL, c'est pourquoi elles utilisent généralement des solutions basées sur Mongo, qu'il vaut mieux oublier. Cependant, pour moi, cela signifie le confort de travailler avec CouchDB, ainsi que l'étude de la conception de structures que non seulement certains bureaucrates seront en mesure de remplir de données. Je pense que je passe mieux mon temps.
Mais le vrai sujet de cet article est ce que j'utilise aujourd'hui. Pas par choix, mais à cause de la politique d'entreprise appliquée indifféremment et aveuglément. Par conséquent, je présenterai une comparaison parfaitement honnête et impartiale de deux produits de base de données en temps réel Google étroitement liés.
Les deux ont le mot Feu dans leurs noms. Une chose dont je me souviens avec tendresse. Le deuxième pour moi est un autre type de feu. Je ne suis pas pressé de dire leurs noms, car dès que je fais cela, nous sommes confrontés au premier gros problème - les noms.
Le premier s'appelle Firebase Real-Time Database et le second Firebase Cloud Firestore . Les deux sont des produits de la suite Firebase de Google. Leurs API sont respectivement nommées
firebase.database(…)et firebase.firestore(…).
En effet, la base de données en temps réel n'est que la base Firebase originale avant que Google ne l'achète en 2014. Ensuite, Google a décidé de créer une copie deFirebase est basé sur le Big Data de l'entreprise et l'a nommé Firestore avec un cloud. J'espère que vous n'êtes pas encore confus. Si vous êtes confus, ne vous inquiétez pas, j'ai moi-même réécrit dix fois cette partie de l'article.
Parce que Firebase doit être cité dans la question Firebase , et Firestore dans la question Firebase, au moins à comprendre il y a quelques années sur Stack Overflow.
S'il y avait un prix pour la pire dénomination des produits logiciels, alors ce cas deviendrait certainement l'un des prétendants. La distance de Hamming entre ces noms est si petite qu'elle confond même les ingénieurs expérimentés, dont les doigts tapent un nom, bien que la tête pense à un autre. Ce sont des plans qui ont lamentablement échoué, inventés avec les meilleures intentions; ils ont accompli la prophétie selon laquelle la base de données serait en feu. Et je ne plaisante pas. L'homme qui a inventé ce schéma de dénomination a causé du sang, de la sueur et des larmes.
Victoire à la Pyrrhus
On pourrait penser que Firestore est un remplacement de Firebase, son descendant de la prochaine génération, mais ce serait une idée fausse. Il est garanti que Firestore ne remplacera pas Firebase. On dirait que quelqu'un en a supprimé tout ce qui est intéressant et a confondu la plupart des autres de différentes manières.
Cependant, un rapide coup d'œil sur les deux produits peut prêter à confusion: ils semblent faire la même chose, principalement via les mêmes API, et même dans la même session de base de données. Les différences sont subtiles et n'apparaissent que grâce à une étude comparative approfondie de la vaste documentation. Ou lorsque vous essayez de porter du code qui fonctionne parfaitement sur Firebase pour fonctionner avec Firestore. Même dans ce cas, vous vous rendez compte que l'interface de la base de données s'allume dès que vous essayez de faire un glisser-déposer en temps réel. Encore une fois, je ne plaisante pas.
Le client Firebase est poli dans le sens où il met en mémoire tampon les modifications et réessaie automatiquement les mises à jour, en donnant la priorité à la dernière écriture. Cependant, Firestore a une limite de 1 opération d'écriture par document par utilisateur et par seconde, et cette limite est imposée par le serveur. Lorsque vous travaillez avec, vous devez vous-même trouver un moyen de le contourner et mettre en œuvre un limiteur de fréquence de rafraîchissement, 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 fait passer pour une API.
Avec cela, nous commençons à voir les premiers signes de la signification de l'existence Firestore. Je me trompe peut-être, mais je soupçonne que quelqu'un de haut niveau dans la direction de Google s'est occupé de l'achat sur Firebase et a simplement dit: «Non mon Dieu, non. C'est inacceptable. Seulement pas sous ma direction. "
Il est sorti de son cabinet et a proclamé:
«Un gros document JSON? Non. Vous diviserez les données en documents séparés, dont chacun ne dépassera pas 1 mégaoctet. "
Il semble qu'une telle limitation ne survivra pas à la première rencontre avec une base d'utilisateurs raisonnablement motivée. Vous savez que ça l'est. Au travail, par exemple, nous avons plus de quinze cents présentations, et c'est parfaitement normal.
Avec cette limitation, vous devrez accepter le fait qu'un «document» dans la base de données ne sera pas comme n'importe quel objet que l'utilisateur appellerait un document.
«Des tableaux de tableaux qui peuvent contenir récursivement d'autres éléments? Non. Les tableaux ne contiendront que des objets ou des nombres de longueur fixe comme le Seigneur l'a voulu. "
Donc, si vous espériez mettre GeoJSON dans votre Firestore, vous constaterez que ce n'est pas possible. Rien de non uniforme n'est autorisé. J'espère que vous aimez Base64 et / ou JSON dans JSON.
Importation et exportation JSON via HTTP, outils de ligne de commande ou panneau d'administration? Non. Vous ne pourrez exporter et importer des données que vers Google Cloud Storage. Il semble donc s'appeler maintenant. Et quand je dis «vous», je fais référence uniquement à ceux qui ont des pouvoirs de propriétaire de projet. Tout le monde peut aller créer des billets. "
Comme vous pouvez le voir, le modèle de données FireBase est facile à décrire. Il contient un énorme document JSON reliant les clés JSON aux chemins d'URL. Si vous écrivez ce qui suit
HTTP PUTdans /FireBase:
{
"hello": "world"
}Il
GET /helloreviendra "world". Cela fonctionne essentiellement exactement comme vous vous y attendez. Une collection d'objets FireBase /my-collection/:idéquivaut à un dictionnaire JSON {"my-collection": {...}}à la racine, dont le contenu est disponible dans /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Cela fonctionne bien si chaque insert a un ID de non-collision, pour lequel le système a une solution standard.
En d'autres termes, la base de données est 100% compatible JSON (*) et fonctionne très bien avec HTTP comme CouchDB. Mais la plupart du temps, vous l'utilisez via une API en temps réel qui résume les Websockets, les autorisations et les abonnements. Le panneau d'administration a les deux capacités, permettant à la fois l'édition en temps réel et l'importation / exportation JSON. Si vous vous en tenez à la même chose dans votre code, vous serez surpris de la quantité de code personnalisé gaspillée lorsque vous réaliserez que le patch et le diff JSON résolvent 90% des tâches d'état persistantes de routine.
Le modèle de données Firestore est similaire à JSON, mais en diffère à certains égards critiques. J'ai déjà mentionné le manque de tableaux à l'intérieur des tableaux. Le modèle de sous-collections doit être des concepts de première classe séparés du document JSON contenant. Comme il n'y a pas de sérialisation prête à l'emploi pour cela, un chemin de code spécialisé est requis pour obtenir et écrire des données. Pour traiter vos propres collections, vous devez écrire vos propres scripts et outils. Le panneau d'administration ne vous permet d'apporter de petites modifications qu'un champ à la fois et n'a pas de capacités d'importation / exportation.
Ils ont pris une base de données NoSQL en temps réel et l'ont transformée en une base non SQL lente avec jointure automatique et une colonne non-JSON distincte. Quelque chose dans l'esprit de 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 de choisir FireBase prêt à l'emploi. Le logiciel dont l'administrateur de base de données grincheux a besoin nécessite un tel niveau d'effort et de calibre de spécialistes qu'il est tout simplement irréaliste pour un créneau dans lequel le produit est censé être bon. Ceci est similaire à la façon dont HTML5 Canvas ne remplace pas du tout Flash s'il n'y a pas d'outils de développement et de lecteur. De plus, Firestore s'enlise dans une quête de propreté des données et de validation stérile, ce qui n'est tout simplement pas conforme à la façon dont l'utilisateur professionnel moyen aime travailler : pour lui, tout est optionnel, car tout est un brouillon jusqu'au bout.
Le principal inconvénient de FireBase est que le client a été créé plusieurs années à l'avance, avant même que la plupart des développeurs Web ne connaissent l'immuabilité. Pour cette raison, 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 envoyés à l'utilisateur, ce qui rend la diff beaucoup plus difficile. Pour les documents volumineux, son mécanisme de transaction basé sur diff mutable est tout simplement inadéquat. Les gars, nous avons déjà
WeakMapJavaScript. C'est confortable.
En façonnant les données selon les besoins et en ne rendant pas les arbres trop volumineux, ce problème peut être contourné. Mais je suis curieux de savoir si FireBase serait beaucoup plus intéressant si les développeurs proposaient une très bonne API client qui utilise l'immuabilité combinée à des conseils solides et pratiques sur la conception de bases de données. Au lieu de cela, ils semblent avoir essayé de réparer ce qui n'est pas cassé, ce qui a aggravé la situation.
Je ne connais pas toute la logique derrière la création de Firestore. Raisonner sur les motifs qui surgissent à l'intérieur de la boîte noire fait également partie du plaisir. Cette juxtaposition de deux bases de données extrêmement similaires mais incomparables est assez rare. Comme si quelqu'un pensait: "Firebase n'est qu'une fonction que nous pouvons émuler dans Google Cloud".mais n'ont pas encore découvert le concept de définition des exigences du monde réel ou de création de solutions utiles qui satisfont toutes ces exigences. «Laissez les développeurs y réfléchir. Rendez juste l'interface utilisateur jolie ... Pouvez-vous ajouter plus de feu? "
Je comprends plusieurs choses sur les structures de données. Je peux clairement voir que le concept de «tout dans un seul grand arbre JSON» est une tentative d'abstraire de la base de données tout sens de structure à grande échelle. S'attendre à ce qu'un logiciel gère simplement toute fractale de structure de données douteuse est fou. Je n'ai même pas besoin d'imaginer à quel point tout peut être mauvais, j'ai mené des audits de code rigoureux et j'ai vu quelque chose dont vous n'avez jamais rêvé . Mais je sais aussi à quoi ressemblent de bonnes structures, comment les utiliser etpourquoi cela devrait être fait . Je peux imaginer un monde dans lequel Firestore semblerait tout à fait logique et les gens qui l'ont créé pensaient avoir fait du bon travail. Mais nous ne vivons pas dans ce monde.
La prise en charge de la création de requêtes dans FireBase est mauvaise par tous les standards, elle n'existe pratiquement pas. Il a certainement besoin d'être amélioré ou au moins révisé. Mais Firestore n'est pas beaucoup mieux, car il est limité aux mêmes index unidimensionnels que ceux trouvés dans le SQL ordinaire. Si vous voulez des requêtes que les gens effectuent sur des données chaotiques, vous avez besoin d'une recherche en texte intégral, de filtres sur plusieurs plages et d'un ordre arbitraire défini par l'utilisateur. En y regardant de plus près, les fonctions de SQL brut sont trop limitées par elles-mêmes. De plus, les seules requêtes SQL que les utilisateurs peuvent exécuter en production sont des requêtes rapides. Vous aurez besoin d'une solution d'indexation spécialisée avec des structures de données sophistiquées. Pour tout le reste, au moins, il devrait y avoir une réduction de carte incrémentielle ou quelque chose de similaire.
Si vous regardez dans la documentation Google à ce sujet, nous espérons que vous serez dirigé vers quelque chose comme BigTable et BigQuery. Cependant, toutes ces décisions sont accompagnées d'un tel volume de jargon de vente d'entreprise épais que vous retournerez rapidement en arrière et commencerez à chercher autre chose.
La dernière chose dont vous avez besoin dans le cas d'une base de données en temps réel est quelque chose de fait par des humains et pour des personnes travaillant sur une échelle salariale pour le leadership.
(*) C'est une blague, il n'y a pas de compatibilité 100% JSON .
La publicité
Vous recherchez un VDS pour le débogage de projets, un serveur pour le développement et le déploiement? Vous êtes définitivement notre client :) Facturation quotidienne des serveurs de différentes configurations, les licences anti-DDoS et Windows sont déjà incluses dans le prix.
