There are so many times you'll be using an API and have the option to request a certain number of responses. What's the best way to determine how many you should request? We're going to discuss that in this article but with few exceptions, I'm going to tell you to maximize your fetch!
The thought process for this began while I was developing an application that would allow the user to view items which are at the Harvard Art Museum, using their API. This was a fun project and there are literally over 200,000 different items available to request in the API. You could look at an almost endless amount of photographs and still have more to see!
So, originally, on the application load I would fetch 16 items from the museum's API which would be displayed in four columns with four rows. At the bottom of the final row, a standard "Load More..." button would appear.
When I first created the application, this button had one sole purpose: Fetch another 16 items and add them to the useState where we are storing the previous 16 items! Now the user has 32 to look at and things are great.
If we have someone who's going to click through a lot, this is going to generate a lot of network requests. More importantly, it's going to use a lot of API calls. Now, Harvard is generous and allows up to 1000 API calls per hour with the use of their free license key that they will grant upon request after the developer fills out a form explaining their use case. Not every API allows so many calls though and even with 1000 per hour, if you have multiple simultaneous users, you will still want to make them stretch as far as you can!
So, what's the solution here?
The Harvard Museum API allows for up to 100 objects to be requested at a time. In my case, I was only requesting 16 at a time. I decided I needed a way to be able to request 100 objects but not actually need to use them all immediately. A new useState case was born.
All of the requested records are stored in state under artRecords and we will fetch 100 at a time, which is our maximum limit. I then decided to create a state called visible and a way to increment that number. Since I want four rows of four columns to appear for the user, I'm setting my increment number to 16.
With that finished, I would need to modify my "Load More" button to allow for this functionality. So, we need to do a few things here:
First, I'm going to change my application from displaying all of the records that were originally in state to a sliced version of that array.
This is the array that will be passed through the application and later mapped out to display the objects.
Next, we will need to modify our "Load More..." button. It's no longer going to do a simple fetch request like it originally did. Here's the new breakdown I developed:
Line 72: Increment the visible number.
By doing this, we will automatically show the user the next 16 items that were stored in State because this will force a reload with the new number of items.
Line 73: After the visible amount was incremented, we're going to check and see if the amount of visible records are greater than the amount of records available. If this is true, we're going to issue an early return and do nothing else here. This line isn't mandatory and not all API's will return the number of total available records.
Lines 74-77: This is the more important line. If we didn't return early yet, we're going to check and see if the amount of visible records are greater than or equal to the number of records we have stored in state. If this is true, we need to fetch the next 100 records and add them to our state.
By proceeding in this manner, we're allowed to request a larger number of objects through the API, display them as-requested by the user, and maximize our network request/API call efficiency.
There are a lot of awesome free API's out there! Let's maximize the requests so that they stay free to use and stay available. That said, even if you're using a paid API: Why not make the most out of each and every call?
Thanks for reading this! I hope it helped you out. If you enjoyed the content, please check back and also follow my journey on Twitter!