Composer Caching

[Ron van der Molen]

For my company i've built a bitbucket integration with our website which generates a dynamic composer repository.

You can compare it with Satis, only that Satis dumps the content statically while we fetch the latest versions on demand based on the settings in our website.

However, our packages are constantly under development and there's often a high throughput of tags which requires a quite fast refresh rate of our dynamic repository packages.json

My question is, is there any limitation of the amount of requests i can make to the Bitbucket API in a certain timespan? Since our packages.json is used in the composer files of our clients, they often call the URL which triggers the fetching of the latest versions of the extensions.

I've integrated a caching backend which caches the versions per package and set it to 3600 seconds in the past, but it was way to slow. At the moment it's set at 300 seconds. I would like to fully remove this cache or set it to something like 60 seconds tops.

Your advice would be great, because i would not want to hit any rate limits, now or in the future. I couldnt find anything on the limits of the Bitbucket API.

Thanks!

[Ron van der Molen · Accepted solution]

It always happens when you just asked the question in a community, but i found the answer here:

https://support.atlassian.com/bitbucket-cloud/docs/api-request-limits/

Maybe it's wise for Atlassian to add this to the reference documentation.

[Ron van der Molen]

For anyone that may be wondering the same, the limit of 1000 repository requests is quite easily reached.

So to counter this, i have actually increased the cache to a day and add a webhook per repository to invalidate the cache on our website for that specific package in case of a tag creation.