Hat jemand Erfahrung mit GraphQL und Firebase? Ich nehme an, man würde die Firebase-Aufrufe im Resolver des relevanten Felds platzieren und eine Variable aus den Requisiten der Komponente an die Argumente der Abfrage übergeben.
Wie können wir mit GraphQL neue Daten in Firebase einfügen?
Antworten:
Um Ihre Frage zu beantworten, gibt es drei Möglichkeiten, wie Sie damit umgehen können.
Wenn Sie Firebase verwenden möchten, können Sie die Firebase-API eins zu eins in GraphQL-Abfragen und -Mutationen abbilden.
Sie können die Firebase-API sicher in GraphQL-Resolver einbinden und auf diese Weise Anrufe tätigen. Dies ist ein gutes Beispiel dafür :
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 }))
},
},
};
Im Wesentlichen verwenden Sie hier Firebase als Datenbank, die so lange funktioniert, bis Sie Ihre Daten in Ihren Resolvern relational abfragen möchten . Ohne die Möglichkeit, Verknüpfungen auf der Serverseite über Ihrem Datenspeicher durchzuführen, stellen Sie in Ihren Resolvern unzählige Roundtrip-Anforderungen an Firebase, um nur eine einzige Anforderung zu erfüllen.
Der Grund, warum die meisten Benutzer Firebase verwenden, liegt in seinen Echtzeitfunktionen und nicht nur in erster Linie als Datenspeicher, da die datenrelationalen Modellierungswerkzeuge in diesem Aspekt ziemlich fehlen. Damit ist es wahrscheinlich besser, mit einer anderen Datenquelle auf GraphQL zu migrieren.
Wenn Sie offen für die Verwendung von BaaS-Produkten wie Firebase sind, können Sie auf ein GraphQL-BaaS umsteigen.
Wenn Sie bereit sind, mithilfe Ihres eigenen Datenspeichers auf eine selbst gehostete Lösung umzusteigen, bietet dies ebenfalls viele Vorteile. Hier sind ein paar große Hitter:
Flexibilität bei der Verwendung Ihres eigenen Datenspeichers und möglicherweise mehrerer Datenspeicher, um den Anforderungen Ihrer spezifischen App gerecht zu werden
Benutzerdefinierte Abfragen und Mutationen
Fügen Sie nativ benutzerdefinierte Logik hinzu, anstatt über Microservices, die an Webhooks in Ihrer API angehängt sind
Führen Sie Ihre eigenen Authentifizierungs- und Berechtigungsmechanismen durch
Wahrscheinlich eine kostengünstigere Lösung
Ich bin mit einigen Empfehlungen hier nicht einverstanden. GraphQL kann auf relationale Weise verwendet werden, aber es kann auch auf NoSQL-Weise verwendet werden. Firebase mit RTD (Real Time Database) und Firestore sollte als NoSQL-Datenbank modelliert werden, da es sich um eine NoSQL-Datenbank handelt! Es gibt Kompromisse bei diesem Ansatz:
1. Optimiertes Lesen:
Als NoSQL-Datenbank sollten die Sammlungen als Ihre Ansichten in Ihren Clients (mobil oder im Web) modelliert werden. Wenn Sie also eine Abfrage durchführen, ist alles bereits zusammengeführt und Sie müssen weder berechnete Requisiten im Client noch Firebase-Funktionen erstellen. Dieser Ansatz macht das Lesen wirklich sehr schnell.
2. De-optimiertes Schreiben:
Der Hauptnachteil hierbei ist, dass Sie dafür verantwortlich sind, jedes Dokument in der Datenbank zu aktualisieren, wenn Sie verwandte Daten berühren (z. B. Aktualisierung des Benutzernamens, des Profilbilds usw.). In diesem Fall sollten Sie jedes Dokument in Ihrer Datenbank finden (z. B. Beiträge, Kommentare usw.) und die Atomizität sicherstellen. Dieser Ansatz wird empfohlen, wenn Sie eine App haben, die weitaus mehr Lesevorgänge als Schreibvorgänge ausführt (wie ein Blog, 7000 Lesevorgänge pro Schreibvorgang als Beispiel).
3. Einfach zu skalieren:
Da Ihre Sammlungen keine engen Beziehungen zu anderen Dokumenten haben, können Sie eine vollständige Sammlung auf nur einem Server haben oder auf viele von ihnen aufteilen. (Deshalb ist Firebase wie DynamoDB billig zu skalieren.)
GraphQL ist nur eine Abfragesprache. Es sollte Ihnen das Abfragen erleichtern, aber nicht vorschreiben, wie Sie Ihre Datenbank modellieren. Sie sollten festlegen, wie Ihre Datenbank, Ihre Abfragen und Mutationen modelliert werden sollen.
TL; DR: GraphQL leuchtet dort, wo Firebase zu kurz kommt. Leistungsstarke Datenmodellierung, flexible und effiziente Abfragen und die offene Spezifikation sind wesentliche Bestandteile von GraphQL, die in Firebase fehlen.
Firebase hat aufgrund seiner begrenzten Datenmodellierung viel Kritik erhalten. Grundsätzlich sind Ihre Daten als ein einziger, riesiger JSON strukturiert, der dieselben Daten mehrmals angibt. Was auf den ersten Blick praktisch erscheint, führt zu nicht verwaltbarem Client-Code, wenn Sie Daten aktualisieren müssen, da Sie alle Verweise auf dieselben Daten manuell nachverfolgen müssen.
Die in GraphQL verwendete Datenstruktur ist dagegen sehr intuitiv und vertraut, da sie als Grafik modelliert wird. Mit der IDL-Syntax können wir unser Datenmodell, das als GraphQL-Schema bezeichnet wird, leicht beschreiben. Für eine Twitter-App könnte das Schema folgendermaßen aussehen:
type Tweet {
id: ID!
title: String!
author: User! @relation(name: "Tweets")
}
type User {
id: ID!
name: String!
tweets: [Tweet!]! @relation(name: "Tweets")
}
Hier definierten wir zwei Typen Tweetund Usermit einigen skalaren Eigenschaften und auch eine Eins-zu-viele - Beziehung zwischen Userund Tweet. Einzelne Datenelemente werden als Knoten bezeichnet - und ein Benutzerknoten kann mit vielen Tweet-Knoten verbunden werden. Diese Datenstruktur ist sowohl einfach als auch flexibel, abgesehen vom JSON-Ansatz von Firebase.
Die flexiblen Abfragefunktionen von GraphQL sind einer der Hauptvorteile. Abfragen sind hierarchisch, dh Sie können Datenanforderungen angeben, die die Diagrammstruktur widerspiegeln. In unserem Twitter-Beispiel haben wir möglicherweise eine Abfrage, um alle Benutzer und ihre Tweets abzurufen:
query {
allUsers {
id
name
tweets {
title
}
}
}
Beachten Sie, dass wir Felder, die wir abfragen möchten, frei einschließen oder weglassen können und sogar über Beziehungen hinweg abfragen können. Dies bedeutet, dass wir weder mehrere Abfragen durchführen noch nicht benötigte Daten abfragen müssen, was GraphQL-Abfragen äußerst effizient macht.
Durch Hinzufügen von Abfrageargumenten zum Mix können Funktionen wie eine benutzerdefinierte Reihenfolge oder Filter hinzugefügt werden , um eine leistungsstarke GraphQL-API zu erhalten .
All das ist mit Firebase einfach nicht möglich.
Die Echtzeitfunktionen von Firebase haben es so beliebt gemacht - aber da die GraphQL-Community im Begriff ist, einen Konsens in Bezug auf Echtzeit zu erzielen , wird auch der größte Vorteil von Firebase zunichte gemacht . Ich empfehle dieses Video-Tutorial zu GraphQL-Abonnements, um die zugrunde liegenden Konzepte besser zu verstehen
Um Ihre Frage zu beantworten: GraphQL übertrifft Firebases in den meisten Aspekten und ist daher die bevorzugte Wahl.
Wenn Sie sich für GraphQL interessieren, empfehlen wir Ihnen Graphcool , das die Stärken von GraphQL mit leistungsstarken Funktionen wie integrierter Authentifizierung und flexiblen Hooks für AWS Lambda oder andere serverlose Funktionen kombiniert , um benutzerdefinierte Geschäftslogik zu implementieren.
Haftungsausschluss: Ich arbeite bei Graphcool :)
Sie können graphql & firebase lokal verwenden . Das ganze schwere Heben kann in einem Webworker durchgeführt werden, um zu vermeiden, dass die Benutzeroberfläche beim Lösen der Anforderung blockiert wird.
Ein Wort zu den "vielen Roundtrips, die zum Lösen der Anfrage erforderlich sind": Wenn Sie sich nicht um die übertragenen Daten kümmern, ist das keine große Sache, da alle "Roundtrips" in demselben Socket-Frame zusammengeführt werden. Wenn Sie jedoch große Frames vermeiden möchten, müssen Sie nur ein wenig dataloadervor Ihre Firebase-Datenbank stellen.
Für Echtzeitaktualisierungen müssen Sie nur Echtzeitereignisse von firebase abonnieren und an den Webworker senden, um sie in echte graphql-Abonnements zu konvertieren, die über Ihr Schema aufgelöst werden können.
Weitere Informationen zu diesem Thema finden Sie in meinem mittleren Beitrag: Echtzeit-Webanwendungen mit Clientbase, GraphQL und Apollo-Client 2.0
Hoffentlich hilft das !
Müssen Sie Firebase verwenden? Es gibt speziellere Dienste für GraphQL, die möglicherweise das bieten, wonach Sie suchen. https://scaphold.io ist eine YC Fellowship Company, die besonders vielversprechend aussieht und Ihnen eine Erfahrung wie eine Feuerbasis bietet, aber auf GraphQL basiert.