Migration der Google Drive API von v2 auf v3

Bei der Integration einer Anwendung mit externen Datenquellen müssen sich die Entwickler bewusst sein, wie sich eine API-Anforderung auf die Leistung auswirken kann. Wenn Sie nicht aufpassen, können Sie leicht Antworten erhalten, die viele unnötige Daten enthalten, was zu Nutzdatengrößen führt, die die Speicherkosten und Netzwerklatenzraten erhöhen.

Hier bei FloQast haben wir große Teile unserer Codebasis in kleinere Repositories sowohl im Backend als auch im Frontend überführt. Da ein Teil unseres Codes nicht mehr in einem Backend-Monolithen gespeichert war, konnten wir eine Verzögerung bei einigen unserer Datenanfragen feststellen. Daher standen wir vor der Herausforderung, unsere Integrationen so weit wie möglich zu straffen, um die gleichen Daten bereitzustellen, die unsere Prozesse benötigen, ohne dass es zu Verzögerungen für unsere Kunden kommt.

Aus diesen Gründen sind wir kürzlich von Version 2 auf Version 3 der Google Drive-API umgestiegen. In diesem Artikel besprechen wir, wie v3 die Leistung optimiert und welche kleinen Änderungen erforderlich sind, um eine App von v2 auf v3 umzustellen.

Warum sollten Sie auf v3 umsteigen?

Einer der Hauptunterschiede zwischen v2 und v3 besteht darin, dass v3 die Leistung verbessert, indem standardmäßig nur eine begrenzte Menge an Daten zurückgegeben wird. Dies ist eine große Veränderung gegenüber v2, wo die Suche nach Dateien standardmäßig alle Datei-Metadaten zurückgab. Um diese Optimierung weiter voranzutreiben, müssen Sie bei den meisten Methoden, die eine Antwort zurückgeben, jetzt die benötigten Felder angeben. Der Empfang nur relevanter Daten auf diese Weise erleichtert den Entwicklern das Leben, da sie sich nicht mehr durch eine riesige JSON-Antwort wühlen müssen, und ermöglicht außerdem eine effizientere Funktionsweise der API, die Antworten schneller liefert.

Sehen wir uns diese Optimierung in Aktion an

Angenommen, wir möchten nach allen Dateien in einem Google Drive-Ordner suchen, damit unsere Anwendung Links zu den Dateien mit Symbolen erstellen kann, die ihren Dateitypen entsprechen. Wir möchten eine Methode erstellen, die ein Array von Ordnerdatenobjekten zurückgibt, das die Datei-ID für den Link, den Dateinamen zur Kennzeichnung des Links und den MimeType zur Bestimmung des zuzuweisenden Symbols enthält.

Hier erfahren Sie, wie Sie das mit Google Drive API v2 erreichen können:

/**
 * Lists all fields of files
 * @param {google.auth.OAuth2} auth An authorized OAuth2 client.
 */
async function listFilesV2(auth) {
  const drive = google.drive({version: 'v2', auth});
  try {
    const res = await drive.files.list();
    const files = res.data.items;
    let fileData = [];
    if (files.length) {
      files.map((file) => {
        fileData.push({
          id: file.id,
          name: file.title,
          mimeType: file.mimeType
        });
      });
    }
    return fileData;
  } catch (err) {
    return console.log('The API returned an error: ' + err);
  }
};

So erhalten wir die Daten, die wir suchen. Standardmäßig würde unser v2-Aufruf jedoch auch mehr als 30 andere Datenfelder zurückgeben, die wir nicht benötigen - und zwar für jede Datei!

Mit einigen geringfügigen Änderungen an unserer Anfrage können wir v3 verwenden, um eine wesentlich effizientere Antwort zu erhalten:

/**
 * Lists kind, id, name, mimetype of files
 * @param {google.auth.OAuth2} auth An authorized OAuth2 client.
 */
async function listFilesV3(auth) {
  const drive = google.drive({version: 'v3', auth});
  try {
    const res = await drive.files.list();
    const files = res.data.files;
    let fileData = [];
    if (files.length) {
      files.map((file) => {
        fileData.push({
            id: file.id,
            name: file.name,
            mimeType: file.mimeType
        });
      });
    }
    return fileData;
  } catch (err) {
    return console.log('The API returned an error: ' + err);
  }
};

Auch ohne Angabe der gewünschten Felder gibt v3 standardmäßig nur 4 Felder zurück(kind, id, name, mimeType). Im Gegensatz zum Ergebnis von v2 bleibt nicht eine riesige Menge ungenutzter Daten übrig, die unsere Antwort verlangsamt. Wir können dies sogar noch weiter optimieren, indem wir den Parameter fields in unserer Anfrage verwenden. Angenommen, wir ändern unseren Anwendungsfall und benötigen nur noch die Datei-ID und den Namen. So können wir unsere Antwort auf die Abfrage dieser Felder beschränken:

/**
 * Lists id & name of files
 * @param {google.auth.OAuth2} auth An authorized OAuth2 client.
 */
 async function listFilesV3Filtered(auth) {
  const drive = google.drive({version: 'v3', auth});
  try {
    const res = await drive.files.list({
      fields: 'files(id, name)'
    });
    const files = res.data.files;
    let fileData = [];
    if (files.length) {
      files.map((file) => {
        fileData.push({
            id: file.id,
            name: file.name,
            mimeType: file.mimeType
        });
      });
    }
    return fileData;
  } catch (err) {
    return console.log('The API returned an error: ' + err);
  }
};

Wie man von v2 auf v3 migriert

Wie Sie sehen können, war der Übergang von v2 zu v3 nicht sehr arbeitsintensiv, aber er hat unsere Anfrage optimiert, indem etwa 30 Datenfelder pro Datei standardmäßig entfernt wurden. Das ist eine enorme Leistungsoptimierung, die unseren Kunden definitiv helfen wird, wenn unsere Anwendung wächst und mehr Daten verarbeiten muss. Hier sind die Schritte, die wir unternommen haben, um unsere v2-Methode auf v3 zu migrieren:

1. Die Versionsnummer von google.drive wurde von v2 auf v3 geändert.
2. Abruf der Dateidaten aus der data.files unserer v3-Antwort anstelle der data.items der v2-Antwort
3. Setzen Sie die Eigenschaft name aus der file.name unserer v3-Antwort anstelle der file.title der v2-Antwort

Das war's! Ziemlich einfach, oder? Google hat auch eine Reihe von Änderungen an v3 vorgenommen, um die Namenskonventionen der API zu verbessern und doppelte Funktionen zu entfernen. Zum Beispiel:

• Die Methode files.list bietet dieselbe Funktionalität wie die Children- und Parents-Sammlungen der Version 2, weshalb diese Sammlungen entfernt wurden
• Die Sammlung " Properties" wurde ebenfalls entfernt, da die Ressource " Files" bereits über das Feld " Properties" verfügt, das die gleichen Daten liefert
• Um eine Datei zu erstellen, verwenden wir statt der files.insert-Methode von v2 nun die files.create-Methode von v3
• Weitere Änderungen der Namensgebung von v2 zu v3 finden Sie in diesem Referenzhandbuch

Mit einer intuitiveren Namensgebung, der Beseitigung von Redundanzen und der Straffung der Antworten bietet v3 Entwicklern viele Vorteile und ist den geringen Aufwand einer Migration auf jeden Fall wert.

Bruce Wayne

Ein milliardenschwerer Industrieller und notorischer Playboy. Obwohl er keine übermenschlichen Kräfte besitzt, ist er einer der klügsten Männer und größten Kämpfer der Welt.