Major Changes You Can Expect from a Shopify API Update
Why Updating Shopify Apps is Important
If you make use of Shopify’s powerful API in your private applications, you may need to be aware of some major changes occurring to the functionality which could cause your Shopify apps to no longer work properly. A Shopify API update may seem daunting, but here’s what you should consider.
About a year ago, Shopify added an API versioning system. Prior to this, any time an update would occur, it could break the functioning of your site immediately. With the versioning system, Shopify provided some leeway for independent developers so that they had some time to upgrade items that went through major changes. Site owners could rely upon earlier versions of the API while preparing for any updates.
Shopify introduces upgrades quarterly and continues to support older versions for a year. Sites are automatically fed the most recent supported API version that will work for their sites. However, after a year, older versions are no longer supported. As a result, private apps that have not upgraded to handle major changes may suddenly find that important parts of their online stores no longer work.
There are two changes that have been implemented in the past year that will cause your site to break unless you upgrade your private app to handle the most recent version of the API. Because of the current health crises, there has been a delay in the normal release schedule from April until July, however, you still need to ensure that you have updated your APIs by then.
The major changes affecting sites with Shopify API version 2020-07 will involve inventory management and pagination methods.
Shopify API Update and the Effects on Inventory Changes
One of the major changes introduced by Shopify API version 2020-07 is the way that shops manage inventory for locations.
Current Shopify Inventory Tracking
Before a Shopify API update, inventory could be associated directly with product variants. You could have one inventory value for each product variant, and you could manage your inventory with just that single value directly on the variant record.
However, many businesses who use Shopify have inventory in multiple physical locations. For this reason, keeping inventory specifically associated with each product became a problem. One store could have a large number of items available in stock, whereas another one could be out; this use case could not be managed by the existing system. In this situation it would be impossible to list different inventories for different stores, if for instance, you wanted to enable pickup at a certain location.
New Inventory Tracking with Shopify Update
As of Shopify API version 2020-07 you will no longer be able to store inventory directly in the product variant record but will instead need to store inventory levels per variant on a location by location basis, even if you have only one location.
Many businesses only have one location, so up until now, they have had no trouble managing inventory. For this reason, many of these businesses have been able to use an older version of the Shopify API to continue delivering inventory information to their sites. Sites that have multiple locations have already been able to use the most recent versions of the API.
As a year has passed, the old version is now being deprecated, meaning that it is no longer being supported. What this means is that even sites with only one location will be unable to store their inventory in the old way and will have to update to the new multi-location-aware inventory method.
In order for your app to properly set the inventory level, you need to find the product variant’s inventory item id, the location id for your location or locations, and create an inventory level record for each variant / location combination.
Those sites with a prior single-level field for quantity will need to migrate or your private Shopify app will no longer work.
Shopify Pagination Changes
The second major change from a Shopify API update has to do with the way that pagination, or listings of products per page are rendered.
Shopify Pagination As We Knew It
When an object (e.g. a product) with a specific type is queried, there are likely to be a large number of records. In the previous system it would return all items for a given page number, and the developer would specify the number of items to return on a page. Normally this would be fine for cases where there are only a few pages of items, however, the larger the page number, the higher the offset (i.e. the number of records to skip) would need to be created by the system, resulting in slow responses. For exceptionally large requests (e.g. millions of records), the page would often time out.
To put this into a real-world example, imagine you are reading a book with 400 pages, and you wanted to get to page 256. On the previous system, it would need to go through each and every page (or grouping of say, 10) until you reached where you needed to go. Now imagine you want to turn to the next page. The system would have had to make a query to the database to find the pages with a specified page number listed in the record.. This is not particularly efficient. Imagine if you were trying to find something in a book that had thousands of pages, or in the case of a business, millions of products?
Shopify Pagination Redefined
If we stick to our book analogy, let us treat it more the way that we would in the real world; you would enter a bookmark, or a “cursor” which would identify where you are. In the new system in Shopify, you would simply use two URLs which will identify the specific location within the set of pages. Instead of using the “page” parameter, it will instead use a cursor-based system, using “next” for the next page, and “prev” for the previous page.
So, for instance, say you had a site listing used cars, and you wanted to bring back everything for a specific “make” (e.g. Toyota), it would bring all of the records but not specify the specific page number with which it is associated, instead we bring back the records and can navigate using the two prev/next URLs that were provided.
The system is still paginated, but the method for retrieving records is different – we instead use supplied URLs.
The Endertech Approach to Shopify Pagination
There is an alternate approach that we at Endertech like to use, which is using the “since_id.” If a user wishes to search for the “latest” or “newest” data, they can filter records using this new id. What the since_id does is bring back all records since a specific record was created.
For example, if we wanted to bring back all records created since the record with ID 1,000,000 was created, , we could set the since_id = 1000000, this will return products with an ID of greater than that number. This works because Shopify assigns an auto-increment primary key to all records in their database.
The way that we handle this programmatically to loop through all newly created records, is that we keep track of the ID during each loop. When we reach the end of the loop, if there are no more records to process, we re-submit the query to retrieve new records with the last ID stored. Shopify then responds with another page worth of data. Once Shopify stops returning data, we know we’ve found that last new record.
Prior to Shopify API version 2020-07, in order to deliver a list of products in pages, Shopify would load one page worth of requests, and on the next call, would load all items for page=2, etc. This is extremely time-consuming and memory-intensive for the application, which could result in slow returns of product pages where a shop offers thousands of items. It only got worse for even larger inventories.
Flexible Adaptations to a Shopify API Update
As more changes occur to any Shopify API update in the future, it makes more sense to remain up to date. Not only will keeping current with the latest API make your site better, not doing so, may cause your site to break.
As we discussed in this article, we can now a) make sure that all shops with different locations can maintain a separate inventory level associated with the product location and not the item, and b) we can ensure that shops with large amounts of inventory will run much faster using either prev/next identifiers, or a since_id to bring back the most recent set of records.