Say we wanted to search for all files in a Google Drive folder in order for our app to create links to the files with icons matching their file types. Receiving only relevant data in this fashion makes life easier for developers, since they will no longer have to weed through a massive JSON response, and it also allows the API to function more efficiently, which delivers responses faster. To further encourage this optimization, most methods that return a response now require that you specify the fields you need. This is a big change from v2, where searching for files would return all file metadata by default. One of the primary differences between v2 and v3 is that v3 improves performance by returning a limited amount of data by default. In this article, we'll discuss how v3 optimizes performance and the small changes needed to transition an app from v2 to v3.

As a result, we were presented with the challenge of streamlining our integrations as much as possible in order to provide the same data our processes needed, without causing a lag for our customers.įor these reasons, we recently migrated from version 2 to version 3 of the Google Drive API. Since some of our code was no longer stored in a back-end monolith, we could notice a delay in some of our data requests. Here at FloQast, we've been going through the process of transitioning large portions of our codebase to smaller repositories on both the backend and the frontend. If you are not careful, you could easily receive responses that contain lots of unnecessary data, resulting in payload sizes that increase memory costs and network latency rates.

When integrating an application with external data sources, developers need to be conscious of how an API request may impact performance.

Google drive api pricing