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
Switch from AnyEvent to IO::Async #1912
Conversation
5878e7c
to
bf533c5
Compare
I pulled some changes from this PR out into #1915 because they are simpler and don't rely on this. Will rebase this once that PR is merged. |
@haarg merged |
IO::Async and Future are friendlier to work with and more perl-ish.
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.
LGTM (though not sure if the sitemap change belongs in the same PR... but that's ok)
The sitemap changes could maybe go in a separate PR, but to handle it sensibly it would have to depend on this one, and require an additional cpanfile.snapshot regeneration. The existing sitemap code doesn't even work properly, and we aren't running it on the servers. |
it's OK with me (i'm known to combine several issues in single PRs :)) |
We use AnyEvent to run multiple HTTP requests simultaneously. This converts those to using Net::Async::HTTP. All of the API model methods have been changed to consistently return futures that can be fetched with
->get
, which should make it easier to clean up how we are using concurrent requests.Additionally includes a rewrite of the site map generation to something that should actually work, and some other prereq cleanups.