We started to migrate our app to the new v2 APIs because the deprecated v1 APIs will be removed in less than three months. Unfortunately, the performance of the new APIs is not satisfactory for many use cases. I already wrote about this last year and would like to share a follow-up with a realistic example in this post.
Scenario
In our app, we display an interactive page tree that includes metadata for each page (see the screenshot below). To retrieve this metadata, we need to make the following requests for each page that becomes visible when the user expands the parent page:
- Get children to find out if the page is a leaf
- Get labels
- Get one content property
- Get the version details for the latest page version
Results
The graph below compares the performance of our current REST v1 implementation with the new REST v2 implementation. The new implementation includes several optimizations: it batches requests, caches results, and parallelizes requests as much as possible without being rate-limited.
As you can see, the new implementation is much slower. On average, we are seeing a slowdown of about 750 ms. Fetching 50 pages and their metadata now takes 30% longer than before.
Too many requests
With the v1 APIs, we only needed a single request and six expansions. With the v2 APIs, we have to assemble all of the data on the client ourselves, which leads to problematic N+1 request patterns. For example, we can fetch 50 pages in a single request, but we need to make 50 * 4 = 200 additional requests to get the metadata listed above.
In other posts on this forum, members of the Confluence team wrote that an increase in the number of requests is expected and that the new APIs have been designed for that. However, we frequently ran into rate-limiting issues during the migration. In our tests, we found out that we can make only ~30 parallel requests for a few seconds without being rate-limited.
This is not enough for the use case described above and will become even more problematic for apps that need to replace more v1 expansions with additional requests.
Thereās also a bug in Confluence that prevents apps from responding to HTTP 429 (too many requests) errors because of how CORS requests are handled by the endpoints. (I already reported the bug, but I havenāt heard back yet.)
Suggestions
I think there are two ways in which performance could be improved: more bulk endpoints and higher rate limits.
The Get pages endpoint accepts an array of page IDs, which allows us to fetch multiple pages in one request. If we had similar endpoints for labels, properties, version details, etc., it would significantly improve performance. Thereās already an open ticket for content properties, but itās still in the āgathering interestā phase.
At least until more bulk endpoints are available, the rate limits should be higher. Otherwise, more complex apps that need to display data for multiple pages will become a lot slower for end users.