-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bitbucket server api rate limiting #24860
base: master
Are you sure you want to change the base?
bitbucket server api rate limiting #24860
Conversation
384b54c
to
9c2ffd8
Compare
Unexpected ChangesetsThe following changeset(s) reference packages that have not been changed in this PR:
Note that only changes that affect the published package require changesets, for example changes to tests and storybook stories do not require changesets. Changed Packages
|
I'm not sure how the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey, question: are you getting the rate limiting when using the BitbucketServerEntityProvider
? 🤔
Looking at the code it doesn't seem you should get any rate limiting
you have changed packages/integration/src/bitbucketServer/config.ts, that's why 😄 |
Thanks for the contribution! |
We added this plugin to scrape our bitbucket server instance, and almost immediately we started getting performance issues on our server. The team that owns that has asked us to make sure we only hit the api around 1 time per second. This PR adds the ability rate limit those calls by making use of the The rate limiting is implemented in the Does this address your concern, or do you still have questions or concerns? |
f9bc959
to
7112134
Compare
my question was more about: are you using the |
we are using the BitbucketServerEntityProvider |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! 👍
plugins/catalog-backend-module-bitbucket-server/src/lib/BitbucketServerClient.ts
Outdated
Show resolved
Hide resolved
plugins/catalog-backend-module-bitbucket-server/src/lib/BitbucketServerClient.ts
Show resolved
Hide resolved
7112134
to
b569090
Compare
plugins/catalog-backend-module-bitbucket-server/src/providers/BitbucketServerEntityProvider.ts
Outdated
Show resolved
Hide resolved
plugins/catalog-backend-module-bitbucket-server/src/providers/BitbucketServerEntityProvider.ts
Outdated
Show resolved
Hide resolved
plugins/catalog-backend-module-bitbucket-server/src/providers/BitbucketServerEntityProvider.ts
Outdated
Show resolved
Hide resolved
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
@freben how would you feel about going back to the approach of putting the throttling into the client? We could make it so that you need to opt into that behavior. If there is no throttling configured no throttling would be applied. The client itself seems to be the only place I can guarantee that throttling is properly applied |
Still waiting for the backstage team to get back from vacation. This should not be marked stale. |
thumbs up for this |
Any chance I could get a new review? This is a critical enhancement for us. If there are still any outstanding concerns please let me know. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey 👋
Apologies for the long turnaround on reviews for this, we've been pretty slammed after the holiday season, so we're just getting back to full capacity again!
I'm thinking that whilst we might get to having some form of FetchService
in the backend, similar to the fetchApiRef
in the frontend, we're not really there yet and we don't know what that's going to look like either. I don't want to be even more of a blocker for this work, so what I would suggest is that we narrow down the changes for what's required for this PR just to the @backstage/plugin-bitbucket*
packages instead, and leave out the other changes for now.
It might need some restructuring of course, to maybe have this in some other config variable or to be set in some other way in the interim and out of the integrations.config
for now, but I think that it's probably easier to go down that path, and then eventually deprecate that way once we have some more thoughts about what we're going to do with a global FetchService
.
Does this make sense for now?
Totally makes sense. I'll restructure things to make that service only for the bitbucket plugins. I can also change the config as @joshjung suggested. I should have something up hopefully as early as tomorrow |
Great! Once you have this done, what I can do is restructure the PR I have for the Gitlab plugin to match the same config format you use. |
Signed-off-by: Kevin Johnson <kljohnson@verisk.com>
Signed-off-by: Kevin Johnson <kljohnson@verisk.com>
Signed-off-by: Kevin Johnson <kljohnson@verisk.com>
Signed-off-by: Kevin Johnson <kljohnson@verisk.com>
Signed-off-by: Kevin Johnson <kljohnson@verisk.com>
746a96c
to
dc28db7
Compare
This is ready for another look now I think |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay and the large amount of comments. This turns out to be a very tricky thing, in part because of previous decisions that are none of your fault, but also because of just the tricky nature of the integrations package and polymorphism. That package is being revamped in some nearish future, making things a lot simpler. But here we are.
Let me summarize the comments:
- The -common packages cannot use node-fetch at all
- The integrations package needs to be kept almost perfectly pristine and must not contain any implementation code
The effect of this is:
- Need to make a node typed package, preferably
@backstage/integration-bitbucket-node
and have all implementation there - Dial back the integrations package even more to exclusively the throttler type change
- Change things to accept a
typeof fetch
making it entirely transparent to their implementations what the fetcher actually is doing.
@@ -20,6 +20,11 @@ integrations: | |||
bitbucketCloud: | |||
- username: ${BITBUCKET_CLOUD_USERNAME} | |||
appPassword: ${BITBUCKET_CLOUD_PASSWORD} | |||
fetch: # optional |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might as well remove this nesting level (in the docs below it's not here)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was something I specifically requested because we were introducing a new object that was going to be shared across multiple configurations for customizing fetch. Since I have to add it in another spot, would it not make sense to have the nesting so that there is a consistent indicator across configuration locations, since most likely this throttling will end up in a lot of spots in the future? What if we also want to add more configurations for fetching?
@@ -32,6 +37,11 @@ integrations: | |||
apiBaseUrl: https://bitbucket.mycompany.com/rest/api/1.0 | |||
username: ${BITBUCKET_SERVER_USERNAME} | |||
password: ${BITBUCKET_SERVER_PASSWORD} | |||
fetch: # optional |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove nesting
BitbucketFetchFunction, | ||
BitbucketFetchService, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really would want to get rid of these types. The core of it is, the integrations package should be left as pristine as is humanly possible. See comments below.
getBitbucketCloudDefaultBranch, | ||
getBitbucketCloudDownloadUrl, | ||
getBitbucketCloudFileFetchUrl, | ||
getBitbucketCloudRequestOptions, | ||
ScmIntegrations, | ||
} from '@backstage/integration'; | ||
import fetch, { Response } from 'node-fetch'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
keep this import
@@ -58,6 +60,8 @@ export class BitbucketCloudUrlReader implements UrlReaderService { | |||
}); | |||
}; | |||
|
|||
private readonly fetch: BitbucketFetchFunction; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
private readonly fetch: BitbucketFetchFunction; | |
private readonly fetch: typeof fetch; |
"node-fetch": "^2.6.7", | ||
"p-throttle": "^4.1.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove
* This service can be configured to throttle the number of requests that can be made. | ||
* @internal | ||
*/ | ||
export class BitbucketFetchService { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you make a @backstage/integration-bitbucket-node
package, it could have a
function createThrottledFetch(options: {
inner: typeof fetch,
throttleByHost: {
[host in string]: ThrottleConfig;
}
}): typeof fetch
or something like that, and make it like a "middleware-like" thing around the inner fetch, like we do when we create the fetchApi for the frontend.
No need for caching fetch implementations in a map. Its internal state will be a Map<string, typeof pThrottle>
instead.
@@ -42,11 +42,13 @@ | |||
}, | |||
"dependencies": { | |||
"@backstage/integration": "workspace:^", | |||
"cross-fetch": "^4.0.0" | |||
"cross-fetch": "^4.0.0", | |||
"node-fetch": "^2.6.7" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove
}, | ||
"devDependencies": { | ||
"@backstage/cli": "workspace:^", | ||
"@openapitools/openapi-generator-cli": "^2.4.26", | ||
"@types/node-fetch": "^2.5.12", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove
@@ -32,9 +36,13 @@ export class BitbucketCloudClient { | |||
return new BitbucketCloudClient(config); | |||
} | |||
|
|||
private readonly fetch: BitbucketFetchFunction; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one should also accept a fetch?: typeof fetch
in its constructor. But we'll see if typescript gets cranky with the node-fetch vs cross-fetch types.
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
I am still working through this. I have been distracted by other priorities at work, but this is still very much on my mind and I intend to have an update posted next week sometime. |
Hey, I just made a Pull Request!
Adds the ability to rate limit calls to the bitbucket server api. If no
rateLimit
is provided in the configuration no rate limiting will be applied.✔️ Checklist
Signed-off-by
line in the message. (more info)