PortfolioAbout This Topic
We implemented mechanisms to work smoothly even when handling hundreds of records, such as during month-end aggregation. This design processes data efficiently while respecting invoicing service API limitations.
Working with API Limits
Most cloud services have API call limits. The invoicing service is no exception, with a "maximum 100 items per request" limit.
| Limit | Details | Impact |
|---|---|---|
| Item limit | 100 items per request | Large data requires multiple requests |
| Rate limit | Limited requests per minute | Continuous access may cause errors |
| Timeout | About 30 seconds per request | Heavy processing may be disconnected |
Automatic Paging
Just request "500 items" from GAS, and the app automatically handles 5 round-trips.
"Please retrieve 500 items"
offset=0, limit=100 → Get 100 items
Rate limit countermeasure
Get 100 items each (2 second wait between)
Return all 500 items to GAS
Why Wait 2 Seconds?
Inserting appropriate wait times between API calls prevents overloading the service. This proactively prevents "too many access" errors.
Wait time is configurable. Depending on service load, it can be set between 1-5 seconds.
Retrieve Only What's Needed (Two-Stage Retrieval)
Even with large numbers of invoices, we first retrieve "just the list" quickly, then get details only for items that need them.
skip_details: true to skip line items. Get only ID, number, partner, date
Filter by partner name or date. Reduce 1000 items to 50
Get details only for the filtered 50 items
Effectiveness Comparison
| Method | With 1000 items | Estimated Time |
|---|---|---|
| Bulk retrieval | Get all details for all items | 2-3+ minutes |
| Two-stage | Details for only 50 after filtering | About 30 seconds |
Concurrency Control
To efficiently make multiple API calls, we implemented concurrency control.
Add 10 detail retrieval requests to queue
Process maximum 2 concurrently
Start next task as each one finishes
Return combined results for all 10
Why 2 Concurrent?
Increasing parallelism too much risks hitting service rate limits. 2 concurrent is a balanced setting for speed and stability.
| Parallelism | Speed | Stability | Assessment |
|---|---|---|---|
| 1 | Slow | Very high | Safe but inefficient |
| 2 | Reasonably fast | High | Good balance |
| 5+ | Fast | Low | High rate limit risk |
Maximum Item Limit
Even if user requests "10000 items," the app limits to 500 maximum.
Extremely large requests cause timeouts or memory issues. Setting appropriate limits ensures system stability.
When You Need More Data
For data beyond 500 items, we recommend splitting by period.
| Approach | Example | Benefit |
|---|---|---|
| Split by period | Retrieve monthly | Stable retrieval |
| Split by partner | Retrieve per partner | Analysis-ready data |
| Split by type | Separate invoices and delivery slips | Lighter processing |
Paging Termination Detection
When repeatedly fetching data, we need to correctly determine "there's no more data to fetch."
Request 100 items
Check count retrieved
What This Design Achieves
For Operations
- Stable bulk processing: Design respecting API limits
- Efficient resource usage: Retrieve only what's needed
- Timeout prevention: Appropriate item limits
For Field Staff
- Stress-free operation: Short wait times even with large data
- Single operation completion: No need to think about paging
- Reliable results: No mid-process stops