Skip to content

Throttle enumerator#45

Merged
GustavoCaso merged 3 commits into
masterfrom
throttle-enumerator
Dec 12, 2019
Merged

Throttle enumerator#45
GustavoCaso merged 3 commits into
masterfrom
throttle-enumerator

Conversation

@kirs

@kirs kirs commented Dec 11, 2019

Copy link
Copy Markdown
Contributor

Let's finally extract throttle enumerator from shopify/shopify. It might be useful for other apps that are building something that's supposed to throttle on DB health. I'm specifically thinking of https://github.com/Shopify/shopify-cloud/pull/155 here.

Comment thread guides/throttling.md Outdated
end

def should_throttle?
@throttle_on.call

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth being defensive around this being a proc? What about returning a boolean?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean validating the return of a proc? Or validating that @throttle_on is a proc?

@GustavoCaso GustavoCaso Dec 12, 2019

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@moechaieb are you saying not passing a proc as the throttle_on variable?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mean validating the return of a proc? Or validating that @throttle_on is a proc?

I'm asking if it's worth doing both. I'm usually not in favour of overly defensive programming. I think you know best what to do here, and my comment was just a suggestion.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not always a proc, it can be anything that responds to call like:

"".method(:upcase)
=> #<Method: String#upcase>

We could make it a bit more friendly and raise if the thing doesn't respond to call, but I find it pretty unlikely scenario to optimize for.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with passing something that is precomputed is that it would be the same value for all the iteration cycle of that job.

@kirs kirs Dec 12, 2019

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a string in my example, yes but for Database::Status.method(:healthy?) it kinda doesn't matter because the method has no state.

More over, throttle_on: Database::Status.method(:healthy?) vs throttle_on: -> { Database::Status.healthy? } saves you an extra stack.

@moechaieb moechaieb left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simple enough. Thanks for extracting this Kir ♥️

@GustavoCaso GustavoCaso left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Kir 🎉

@GustavoCaso

Copy link
Copy Markdown
Contributor

I can take care of deploying it and updating core with the latest version.

@GustavoCaso GustavoCaso merged commit 4b66b8c into master Dec 12, 2019
@GustavoCaso GustavoCaso deleted the throttle-enumerator branch December 12, 2019 20:07
@GustavoCaso GustavoCaso temporarily deployed to rubygems December 13, 2019 19:45 Inactive
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants