Firebase et GraphQL

Question

Quelqu'un a-t-il de l'expérience avec GraphQL et Firebase ? Je pense qu'il faudrait placer les appels à Firebase dans le résolveur du champ concerné, en passant une variable des props du composant dans les arguments de la requête.

Comment insérer de nouvelles données dans Firebase en utilisant GraphQL ?

Answer 1

Pour répondre à votre question, il y a trois façons vous pouvez vous en occuper.

1. Firebase et GraphQL

Si vous avez décidé d'utiliser Firebase, vous pouvez établir une correspondance univoque entre l'API de Firebase et les requêtes et mutations GraphQL.

Vous pouvez certainement envelopper l'API Firebase dans des résolveurs GraphQL et effectuer des appels de cette manière. En voici un bon exemple :

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 }))
        },
    },
};

Essentiellement, ce que vous faites ici est d'utiliser Firebase comme une base de données, qui fonctionne jusqu'à ce que vous souhaitiez 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 requête.

La raison pour laquelle la plupart des gens utilisent Firebase est pour ses capacités en temps réel, et non pas principalement comme un simple magasin de données, car les outils de modélisation relationnelle des données dans cet aspect sont assez pauvres. Dans ce cas, il est probablement préférable de migrer vers GraphQL en utilisant une autre source de données.

2. Backend GraphQL en tant que service

Si vous êtes disposé à utiliser des produits BaaS comme Firebase, vous pouvez envisager de passer à un BaaS GraphQL.

3. GraphQL auto-hébergé

Si vous êtes prêt à passer à une solution auto-hébergée utilisant votre propre magasin de données, cela présente également de nombreux avantages. En voici quelques-uns :

• La possibilité d'utiliser votre propre magasin de données, voire plusieurs, pour répondre aux besoins spécifiques de votre application.

• Requêtes et mutations personnalisées

• Ajouter une logique personnalisée de façon native plutôt que par l'intermédiaire de microservices attachés à des webhooks dans votre API.

• Mettez en place vos propres mécanismes d'authentification et d'autorisation

• Probablement une solution moins coûteuse

Answer 2

Je ne suis pas du tout d'accord avec certaines recommandations. GraphQL peut être utilisé de manière relationnelle mais aussi de manière NoSQL. Firebase, avec sa base de données en temps réel (RTD) et Firestore, devrait être modélisé comme une base de données NoSQL car c'est une base de données NoSQL ! Cette approche comporte des inconvénients :

1. Lecture optimisée :

Comme il s'agit d'une base de données NoSQL, les collections doivent être modélisées comme vos vues dans vos clients (mobile ou web), de sorte que lorsque vous effectuez une requête, tout est déjà fusionné et vous n'avez pas besoin de faire des props calculés dans le client ou les fonctions Firebase. Cette approche rend la lecture vraiment VRAIMENT rapide.

2. Écriture dé-optimisée :

Le principal inconvénient est qu'il vous incombe de mettre à jour chaque document de la base de données si vous modifiez des données connexes (comme la mise à jour du nom d'utilisateur, de la photo de profil, etc.) Dans ce cas, vous devez trouver chaque document dans votre base de données (par exemple, les messages, les commentaires, etc.) et assurer l'atomicité. Cette approche est recommandée si vous avez une application qui va avoir beaucoup plus d'opérations de lecture que d'opérations d'écriture (comme un blog, 7000 lectures pour 1 écriture par exemple).

3. Facile à mettre à l'échelle :

Comme vos collections n'ont pas de relations strictes avec d'autres documents, vous pouvez avoir une collection complète sur un seul serveur ou la répartir sur plusieurs d'entre eux. (C'est pourquoi Firebase est bon marché à l'échelle, comme DynamoDB).

GraphQL n'est qu'un langage d'interrogation. Il doit vous permettre d'interroger facilement les choses, mais il ne doit pas vous dicter la façon dont vous modélisez votre base de données. Vous devez dicter la façon de modéliser votre base de données, vos requêtes et vos mutations.

Answer 3

TL;DR : GraphQL brille là où Firebase échoue. Une modélisation puissante des données, des requêtes flexibles et efficaces et une spécification ouverte sont autant d'éléments essentiels de GraphQL qui font défaut à Firebase.

Modélisation puissante des données

Firebase a fait l'objet de nombreuses critiques en raison de sa modélisation limitée des données. Fondamentalement, vos données sont structurées comme un seul et énorme JSON qui énonce les mêmes données plusieurs fois. Ce qui semble pratique à première vue se traduit par un code client ingérable chaque fois que vous devez mettre à jour des données, car vous devez garder la trace des éléments suivants todo les références aux mêmes données manuellement.

En revanche, la structure de données utilisée dans GraphQL est très intuitive et familière, car elle est modélisée sous forme de graphe. En utilisant le 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")
}

Nous avons défini ici deux types Tweet y User avec certaines propriétés scalaires et aussi un relation de type "un à plusieurs". entre User y Tweet . Les éléments de données individuels sont appelés noeuds - et un noeud utilisateur peut être connecté à de nombreux noeuds tweet. Cette structure de données est à la fois simple et flexible, contrairement à l'approche JSON de Firebase.

Des requêtes flexibles et efficaces

La souplesse des capacités d'interrogation de GraphQL est 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 graphe. Dans notre exemple Twitter, nous pourrions avoir une requête pour récupérer tous les utilisateurs et leurs tweets :

query {
  allUsers {
    id
    name
    tweets {
      title
    }
  }
}

Notez que nous pouvons librement inclure ou exclure les champs que nous souhaitons interroger, et que nous pouvons même effectuer des recherches dans plusieurs 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 afin d'obtenir une 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 comme la communauté GraphQL est sur le point d'atteindre un consensus concernant le temps réel En conséquence, le plus grand avantage de Firebase est également réduit à néant. Je recommande ce tutoriel vidéo sur les abonnements GraphQL pour mieux comprendre les concepts sous-jacents

Conclusion

Donc, pour répondre à votre question : GraphQL surpasse Firebases dans la plupart des aspects, ce qui en fait le choix privilégié.

Si vous vous intéressez à GraphQL, je vous encourage à consulter le site suivant Graphcool qui combine les forces de GraphQL avec des fonctionnalités puissantes comme l'authentification intégrée et des crochets flexibles pour AWS Lambda ou d'autres fonctions sans serveur pour mettre en œuvre une logique commerciale personnalisée.

Clause de non-responsabilité : je travaille chez Graphcool :)

Answer 4

Vous pouvez utiliser graphql et firebase localement. . Tout le travail lourd peut être effectué 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 requête" : si vous ne vous souciez pas des données transférées, ce n'est pas si grave puisque tous les "allers-retours" sont fusionnés dans la même trame de socket. Mais si vous voulez éviter les grandes trames, il suffit de mettre un peu de dataloader devant votre base de données firebase.

Pour les mises à jour en temps réel, il suffit de s'abonner à des événements en temps réel à partir de firebase et de les envoyer au webworker pour les convertir en abonnements graphql réels qui peuvent être résolus par votre schéma.

Vous pouvez trouver plus d'informations sur ce sujet dans mon post sur medium : Applications web en temps réel "côté client uniquement" avec Firebase, GraphQL et apollo-client 2.0

J'espère que cela vous aidera !

Answer 5

Êtes-vous obligé d'utiliser Firebase ? Il existe des services plus spécifiques à GraphQL qui peuvent offrir ce que vous recherchez. https://scaphold.io est une entreprise de l'association YC Fellowship qui semble particulièrement prometteuse et vous offre une expérience similaire à celle de Firebase, mais elle est alimentée par GraphQL.