Migration der Google Drive-API von v2 auf v3

Bei der Integration einer Anwendung mit externen Datenquellen müssen sich Entwickler darüber im Klaren sein, wie sich eine API-Anfrage auf die Leistung auswirken kann. Wenn Sie nicht aufpassen, könnten Sie leicht Antworten erhalten, die viele unnötige Daten enthalten, was zu Nutzlastgrößen führt, die die Speicherkosten und die Netzwerklatenzraten erhöhen. Hier bei FloQast haben wir den Prozess der Umstellung großer Teile unserer Codebasis auf kleinere Repositorys auf beiden Backend und die Frontend. Da ein Teil unseres Codes nicht mehr in einem Backend-Monolith gespeichert war, konnten wir bei einigen unserer Datenanfragen eine Verzögerung feststellen. Daher standen wir vor der Herausforderung, unsere Integrationen so weit wie möglich zu optimieren, um dieselben Daten bereitzustellen, die unsere Prozesse benötigten, ohne dass es zu Verzögerungen für unsere Kunden kommt. Aus diesen Gründen haben wir kürzlich von Version 2 auf Version 3 der Google Drive-API migriert. In diesem Artikel besprechen wir, wie v3 die Leistung optimiert und welche kleinen Änderungen für den Übergang einer App von v2 auf v3 erforderlich sind.

Warum sollten Sie auf Version 3 upgraden?

Einer der Hauptunterschiede zwischen v2 und v3 besteht darin, dass v3 die Leistung verbessert, indem standardmäßig eine begrenzte Datenmenge zurückgegeben wird. Dies ist eine große Änderung gegenüber Version 2, bei der die Suche nach Dateien standardmäßig alle Dateimetadaten zurückgeben würde. Um diese Optimierung weiter zu fördern, erfordern die meisten Methoden, die eine Antwort zurückgeben, jetzt, dass Sie die benötigten Felder angeben. Auf diese Weise nur relevante Daten zu erhalten, erleichtert Entwicklern das Leben, da sie nicht mehr eine umfangreiche JSON-Antwort durchsuchen müssen. Außerdem kann die API dadurch effizienter arbeiten, wodurch Antworten schneller geliefert werden.

Sehen wir uns diese Optimierung in Aktion an

Angenommen, wir wollten nach allen Dateien in einem Google Drive-Ordner suchen, damit unsere App 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, die die Datei-ID für den Link, den Dateinamen zur Bezeichnung des Links und den MimeType enthalten, um zu bestimmen, welches Symbol zugewiesen werden soll. So können wir das mit Google Drive API v2 erreichen:

/**
 * 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);
  }
};

Dies gibt uns die Daten, nach denen wir suchen. Standardmäßig würde unser v2-Aufruf jedoch auch mehr als 30 andere Datenfelder zurückgeben, die wir nicht benötigen... für jede Datei!

Mit ein paar geringfügigen Änderungen an unserer Anfrage können wir Version 3 verwenden, um eine viel optimiertere 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 (kind, id, name, mimeType) zurück. Im Gegensatz zum Ergebnis von v2 bleibt uns keine riesige Menge ungenutzter Daten übrig, die unsere Reaktion verlangsamt haben. Wir können dies noch weiter optimieren, indem wir auf unsere Anfrage den Parameter fields verwenden. Nehmen wir zum Beispiel an, wir ändern unseren Lösung und benötigen nur die Datei-ID und den Namen. So können wir unsere Antwort so einschränken, dass nur diese Felder angefordert werden:

/**
 * 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);
  }
};

So migrieren Sie von v2 zu v3

Wie Sie sehen können, war der Übergang von v2 zu v3 nicht viel Arbeit, aber er hat unsere Anfrage optimiert, indem standardmäßig ungefähr 30 Datenfelder pro Datei 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. Unsere google.drive-Versionszeichenfolge wurde von v2 auf v3 geändert
2. Hat die Dateidaten aus den data.files unserer v3-Antwort statt aus den data.items von v2 abgerufen
3. Stellen Sie die Eigenschaft name aus file.name unserer v3-Antwort anstelle von file.title von v2 ein

Das war's! Ziemlich einfach, oder? Google hat auch eine Reihe von Änderungen an Version 3 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 von v2, daher wurden diese Sammlungen entfernt
• Die Properties-Auflistung wurde ebenfalls entfernt, da die Ressource Files bereits über das Eigenschaftenfeld verfügt, das dieselben Daten enthält.
• Um eine Datei zu erstellen, verwenden wir jetzt statt der files.insert-Methode von v2 die files.create von v3
• Für weitere Namensänderungen von v2 zu v3 dieses Referenzhandbuch ansehen

Mit intuitiverer Benennung, Beseitigung von Redundanzen und optimierten Antworten bietet v3 Entwicklern viele Vorteile und ist definitiv den kleinen Aufwand für die Migration wert.