Firebase & GraphQL?
Est-ce que quelqu'un a déjà utilisé les deux?
Je pense que l’on placerait les appels firebase dans le résolveur du champ approprié, en passant une variable des accessoires de composants dans les arguments de la requête.
Dites-nous ce que vous en pensez!
Pour répondre à votre question, il existe trois méthodes pour y remédier.
1. Firebase & GraphQL
Si vous souhaitez utiliser Firebase, vous pouvez mapper un à un les API de Firebase en requêtes GraphQL et en mutations.
Vous pouvez certainement encapsuler l'API Firebase dans des résolveurs GraphQL et effectuer des appels de cette façon. C'est un bon exemple de cela :
const ref = path => firebase.database().ref(path)
const getValue = path => ref(path).once('value')
const mapSnapshotToEntities = snapshot => snapshot.val().map((value, id) => ({ id, ...value }))
const getEntities = path => getValue(path).then(mapSnapshotToEntities)
const resolvers = {
Author: {
posts(author) {
return getEntities('posts').then(posts => filter(posts, { authorId: author.id }))
},
},
Post: {
author(post) {
return getEntities('authors').then(posts => filter(authors, { id: authorId }))
},
},
};
En gros, vous utilisez ici Firebase comme base de données, qui fonctionne jusqu'à ce que vous vouliez interroger vos données de manière relationnelle dans vos résolveurs . Sans la possibilité d'effectuer des jointures côté serveur au-dessus de votre magasin de données, vous ferez des tonnes de requêtes aller-retour à Firebase dans vos résolveurs pour répondre à une seule demande.
La plupart des gens utilisent Firebase pour ses fonctionnalités temps réel, et pas uniquement comme magasin de données, car les outils de modélisation relationnelle de données dans cet aspect sont plutôt absents. Avec cela, vous feriez probablement mieux de migrer vers GraphQL en utilisant une source de données différente.
2. GraphQL Backend en tant que service
Étant donné que vous êtes prêt à utiliser des produits BaaS tels que Firebase, vous pouvez envisager de passer à un système BaGa GraphQL.
3. GraphQL auto-hébergé
Si vous êtes prêt à passer à une solution auto-hébergée à l'aide de votre propre magasin de données, cela présente également de nombreux avantages. Voici quelques gros frappeurs:
Flexibilité d'utiliser votre propre magasin de données et éventuellement plusieurs pour répondre aux besoins de votre application
Requêtes personnalisées et mutations
Ajoutez nativement une logique personnalisée au lieu de via des microservices attachés à des Webhooks dans votre API
Faites rouler vos propres mécanismes d'authentification et d'autorisation
Probablement une solution à moindre coût
Je suis fortement en désaccord avec certaines recommandations ici. GraphQL peut être utilisé de manière relationnelle, mais il peut également être utilisé de manière NoSQL. Firebase, avec sa base de données RTD (Real Time Database) et Firestore, devrait être modélisé comme une base de données NoSQL, car il s'agit d'une base de données NoSQL! Il y a des compromis à cette approche:
1. Lecture optimisée:
En tant que base de données NoSQL, les collections doivent être modélisées comme vos vues dans vos clients (mobile ou Web). Ainsi, lorsque vous effectuez une requête, tout est déjà fusionné et vous n'avez pas à créer d'accessoires calculés dans le client ni dans les fonctions Firebase. Cette approche rend la lecture vraiment VRAIMENT rapide.
2. Écriture désoptimisée:
Le principal inconvénient ici est qu’il vous incombe de mettre à jour tous les documents de la base de données si vous touchez des données connexes (comme la mise à jour du nom d’utilisateur, la photo du profil, etc.). Dans ce cas, vous devez trouver tous les documents de votre base de données (par exemple: articles, commentaires, etc.) et en assurer l’atomicité. Cette approche est recommandée si vous avez une application qui aura beaucoup plus d'opérations de lecture que d'écriture (comme un blog, 7 000 lectures sur une écriture à titre d'exemple).
. Facile à mettre à l'échelle:
Comme vos collections n’ont pas de relations solides avec d’autres documents, vous pouvez avoir une collection complète sur un seul serveur ou la scinder en plusieurs. (C’est pourquoi Firebase est peu coûteux à l’échelle, comme DynamoDB.)
GraphQL n'est qu'un langage de requête. Vous devriez pouvoir facilement interroger des objets, mais cela ne devrait pas dicter votre modélisation de la base de données. Vous devriez dicter comment modéliser votre base de données, vos requêtes et vos mutations.
TL; DR: GraphQL brille là où Firebase manque. Une modélisation de données puissante, des requêtes souples et efficaces et la spécification ouverte sont des éléments essentiels de GraphQL qui font défaut avec Firebase.
Modélisation de données puissante
Firebase a reçu de nombreuses critiques sur la base de sa modélisation de données limitée. Fondamentalement, vos données sont structurées comme un seul et grand JSON qui énonce les mêmes données plusieurs fois. Ce qui semble pratique au premier abord entraîne un code client ingérable lorsque vous devez mettre à jour des données, car vous devez suivre toutes les références manuellement. .
La structure de données utilisée dans GraphQL est quant à elle très intuitive et familière, car elle est modélisée sous forme de graphique. En utilisant syntaxe IDL , nous pouvons facilement décrire notre modèle de données, appelé schéma GraphQL. Pour une application Twitter, le schéma pourrait ressembler à ceci:
type Tweet {
id: ID!
title: String!
author: User! @relation(name: "Tweets")
}
type User {
id: ID!
name: String!
tweets: [Tweet!]! @relation(name: "Tweets")
}
Ici, nous avons défini deux types Tweet et User avec des propriétés scalaires et également une relation relation un à plusieurs entre User et Tweet. Les éléments de données uniques sont appelés nœuds - et un nœud utilisateur peut être connecté à de nombreux nœuds Tweet. Cette structure de données est à la fois simple et flexible, à l’exception de l’approche JSON de Firebase.
Requêtes flexibles et efficaces
Les capacités de requête flexibles de GraphQL constituent l’un de ses principaux avantages. Les requêtes sont hiérarchiques, ce qui signifie que vous pouvez spécifier des exigences de données qui reflètent la structure du graphique. Dans notre exemple Twitter, nous pourrions avoir une requête pour extraire tous les utilisateurs et leurs tweets:
query {
allUsers {
id
name
tweets {
title
}
}
}
Notez que nous pouvons librement inclure ou omettre des champs que nous voulons interroger, et nous pouvons même interroger des relations. Cela signifie que nous n'avons pas besoin d'effectuer plusieurs requêtes ni d'interroger des données inutiles, ce qui rend les requêtes GraphQL extrêmement efficaces.
En ajoutant des arguments de requête au mélange, nous pouvons ajouter des fonctionnalités telles qu'un ordre personnalisé ou des filtres pour obtenir ne puissante API GraphQL .
Tout cela n’est tout simplement pas possible avec Firebase.
Données en temps réel
Les capacités en temps réel de Firebase l’ont rendu si populaire - mais depuis que la communauté GraphQL est sur le point d’atteindre n consensus sur le temps réel , le plus gros avantage de Firebase est également annulé. Je recommande ce didacticiel vidéo sur les abonnements GraphQL pour mieux comprendre les concepts sous-jacents
Conclusion
Donc, pour répondre à votre question: GraphQL dépasse Firebases dans la plupart des aspects, ce qui en fait le choix préféré.
Si vous êtes intéressé par GraphQL, je vous encourage à consulter Graphcool qui combine les points forts de GraphQL avec des fonctionnalités puissantes telles que l'authentification intégrée et des points d'ancrage souples à AWS Lambda ou d'autres fonctions sans serveur pour mettre en œuvre une logique métier personnalisée.
Disclaimer: Je travaille chez Graphcool :)
Vous pouvez utiliser graphql & firebase localement . Tout le travail lourd peut être fait dans un webworker pour éviter de bloquer l'interface utilisateur lors de la résolution de la demande.
Un mot sur "les nombreux allers-retours nécessaires pour résoudre la demande": si les choses ne vous gênent pas pour les données transférées, ce n'est pas si grave, car tous les "allers-retours" sont fusionnés dans le même cadre de socket. Mais si vous voulez éviter les grosses images, il vous suffit de placer un petit dataloader devant votre base de données firebase.
Pour les mises à jour en temps réel, il vous suffit de vous abonner aux événements en temps réel de firebase et de les envoyer au webworker pour les convertir en abonnements graphql réels pouvant être résolus via votre schéma.
Vous trouverez plus d’informations sur ce sujet dans mon article de média: applications Web temps réel "côté client" avec Firebase, GraphQL et apollo-client 2.
J'espère que ça t'as aidé !
Devez-vous utiliser firebase? Il existe des services plus spécifiques à GraphQL qui peuvent offrir ce que vous recherchez. https://scaphold.io est un YC Société de parrainage qui semble particulièrement prometteuse et qui vous procure une expérience comparable à une base de feu, mais qui fonctionne avec GraphQL.