So bringen Sie Apollo 2.0 mit GraphQL + -Subskriptionen zum Laufen

(mit einer Neigung zu Meteor)

Update (28. November 2017): Das Schlüsselwort "Cache" aus dem NPM-Paket "apollo-cache-inmemory" wurde durch "InMemoryCache" ersetzt. Der neue Code spiegelt den aktuellsten Arbeitscode wider. Wenn Sie weitere Probleme haben, melden Sie diese bitte, da wir versuchen, mit den neuesten Änderungen von Apollo Schritt zu halten.

Derzeit herrscht großes Chaos, da die Entwickler feststellen, dass Apollo 2.0 die vorherigen 1.0-Implementierungen grundlegend geändert hat und die offiziellen Dokumente und die meisten Online-Beispiele nun veraltet sind. Ich habe kürzlich 2.0 zum Laufen gebracht (mit Abonnements!) Und ich dachte, ich würde viele von der Mühe der Forum-Jagd ersparen. Für meine Zwecke habe ich dies in Meteor implementiert, aber es ist nur ein Sprung, ein Sprung und ein Sprung zum Knoten.

TL; DR

Eine voll funktionsfähige Beispiel-App finden Sie hier.

Bevor wir anfangen

Ich überlasse GitHub den gesamten Code-Satz und spreche hier nur über einige der Hauptkomponenten, insbesondere die Teile, die sich geändert haben. Ab dem 28. November 2017 funktioniert hier alles und ist korrekt.

Was wirst du brauchen

Apollo 2.0 hat SubscriptionManager, networkInterface und einige andere Dinge zugunsten von Apollo-Link abgeschafft. Das ist ein gutes Zeichen, denn Apollo reift und wird jetzt zu einer Plattform, auf der andere Entwickler Plugins erstellen können. Dies wird jedoch nur in neueren Versionen von Apollo unterstützt und wir müssen einige manuelle Upgrades durchführen, um alle anderen Pakete synchron zu halten.

Sie benötigen die folgenden NPM-Pakete (beachten Sie die Versionen):

apollo-client @ beta
apollo-cache-inmemory @ beta
apollo-link@0.7.0
apollo-link-http@0.7.0
apollo-link-ws@0.5.0
graphql-abonnements
Abonnements-Transport-ws
Apollo-Server-Express
ausdrücken
graphql
graphql-tools
Body-Parser

Wenn Sie Meteor verwenden, sind auch die folgenden Pakete hilfreich:

meteor add apollo swydo: blaze-apollo swydo: graphql webapp

(Wenn Sie React oder Vue verwenden, können Sie auch etwas anderes als swydo: blaze-apollo verwenden.)

Der Kunde

Die meisten der größten Änderungen wurden auf der Client-Seite vorgenommen. Ihr Kunde (mit Abonnements) sieht jetzt ungefähr so ​​aus:

Der Server

Im Gegensatz zum Client verwendet dieses Beispiel mehr Meteor-spezifischen Code. Überprüfen Sie die Links in den Kommentaren, um zu erfahren, wie Sie bestimmte Teile mit etwas wie Express in allgemeineren Code konvertieren können, falls dies gewünscht wird. Oder benutze einfach Meteor.

Resolver

Hier ein kurzer Blick auf unsere Resolver. Es gibt hier nicht viele Änderungen, aber wenn Sie neu in Abonnements sind, können Sie diese hier auf dem Server in Aktion sehen.

Anmerkungen

Erstens ist es wichtig, dass Sie beim Veröffentlichen und Abonnieren von GraphQL wissen, dass Sie jedes Mal manuell veröffentlichen müssen, wenn eine Änderung auf dem Server vorgenommen wurde. Auf diese Weise werden Aktualisierungen sofort auf den Client übertragen. (Meteoriten sind möglicherweise nicht daran gewöhnt, da sie dies immer kostenlos erhalten haben.)

Zweitens funktioniert das obige Beispiel einwandfrei, wenn Sie nur Änderungen an Ihren Daten durch GraphQL-Mutationen vornehmen. Wenn Sie jedoch auch Daten von anderen Orten aktualisieren und möchten, dass Abonnements auf diese Änderungen genauso schnell reagieren, möchten Sie pubsub.publish ("exampleSub", {exampleSub: data}) aufrufen. Wo immer diese Änderungen vorgenommen werden, wobei exampleSub der Name Ihres Abonnements ist und data Ihr vollständiges Objekt für diese Entität ist, das Ihrem GraphQL-Schema entspricht (im obigen Beispiel sind es alle Daten, die zu dieser Person gehören).

Drittens wird in den offiziellen Apollo-Dokumenten von der Verwendung von PubSub in der Produktion abgeraten, da es nicht auf mehrere Server skaliert werden kann. Wenn Sie groß genug sind, um Ihre App auf mehreren Servern auszuführen, sollten Sie eine PubSub-Implementierung verwenden, die dies unterstützt, z. B. Redis, MQTT oder RabbitMQ.

Über Pitchly

Mein Name ist Michael und ich bin Senior Product Engineer bei Pitchly. Wir vereinfachen die Verwaltung und sofortige Suche von Informationen in Ihrem gesamten Unternehmen und exportieren diese Informationen in eine Vielzahl visueller Formate. Meteor, GraphQL und Apollo sind ein großer Teil dessen, was wir verwenden. Wir kommen auch aus Des Moines, Iowa. Sicher schneit es hier, aber wir haben auch ein paar ziemlich tolle Mais!

Wenn Sie Fragen zu unserer Arbeit, unserem Leben oder zu GraphQL oder Meteor haben, können Sie sich an uns wenden. Wir stellen ein!

Webseite - Twitter - LinkedIn

GitHub