2016-08-04 2 views
1

Ich wickle einen älteren REST-API-Dienst mit einem Apollo-Server. Aufrufe an den REST-Dienst führen zu einem JSON-Objekt, das die Nutzlast 2 bis 3 Ebenen tief nistet. Zum Beispiel:Apollo Server - parse REST-Ergebnis in Connector, Resolver oder Model

Und um die Sache noch weiter zu komplizieren, sind das Verschachtelungsmuster und die Knotennamen für jeden Ressourcenendpunkt unterschiedlich. Meine Frage ist also, da jedes Ressourcenergebnis eine benutzerdefinierte Manipulation benötigt, wo es am besten ist: im Connector, Resolver oder Model.

Stecker

Wenn in dem Connector erfolgen, dann wird eine benutzerdefinierte Methode für jede Ressource benötigt. Scheint wie eine Menge Standard.

public fetchCats(resource: string) {  
    return new Promise<any>((resolve, reject) => { 
     request.get(url, (err, resp, body) => { 
     err ? reject(err) : resolve(JSON.parse(body).MRData.CatTable.Cats) 
     }) 
     }) 
    } 

Resolver

Die Resolver-Methode erhält ein Versprechen, aber das Ergebnis nicht manipuliert werden kann:

const allCats = (_, params, context) => context.cat.getCats() 
.then((data) => { // to late to manipulate data here }) 

Modell

Das Modell sieht vielversprechend aus, aber nicht ganz sicher, wie um es zu strukturieren:

public getCats() { 
    const cats = this.connector.fetchCats('/cats.json'); 
    return cats; 
    } 

Apollo wird (meistens) in REST-APIs integriert sein. Ich freue mich darauf, den besten Weg für diesen Fall zu finden.

Antwort

2

Ich würde im Allgemeinen empfehlen, die Analyse im Connector zu tun, weil sie über die Details der Backends abstrahieren sollten. Wenn Connectors über das Backend abstrahieren, sollten Sie technisch in der Lage sein, ein Backend gegebenenfalls gegen ein anderes zu tauschen. Sie könnten beispielsweise vom Abfragen einer REST-API zum direkten Senden von Abfragen an die Datenbank wechseln, wo dies sinnvoll ist.

Die Konsequenz daraus ist, dass Sie für jede REST-API einen neuen Connector erstellen müssen, da keine zwei REST-APIs identisch sind.

+0

Sie bringen einen guten Punkt mit der Abstraktionsschicht. Die Lösung besteht also darin, fetch() und fetchPage() für jeden Ressourcentyp zu erstellen, da diese bestimmte REST-API einen benutzerdefinierten Knotennamen pro Ressource erstellt. – jboothe

+0

Oder besser übergeben Sie noch resource_type Argument zu fetch() - so etwas wie 'fetch (url, resourceType)' und dann ENUMs wie 'CAT_TYPE =" MRData.CatTable.Cats "' und 'DOG_TYPE =" MRData.DogTable.Dogs "' um herauszufinden, welche Parse-Struktur für jede Ressource verwendet werden soll. – jboothe