WIP: add paginated versions API

[nappa85]

Made some assumptions here, feel free to comment.

• didn't know if the issue was about creating a new API or editing the current one
• there seems to be multiple APIs serving versions (e.g. also /crates/:crate_id returns these infos)
• data is sorted by semver in code, this obviously isn't compatible with pagination, so I've added query sort by created_at to mitigate the problem, but I'm quite not sure about it

Still haven't checked if it need some edits frontend-side

Resolves #5292

[Turbo87]

didn't know if the issue was about creating a new API or editing the current one

I guess the easiest way for now would be to retrofit it to the existing endpoint but have it only paginated when per_page is explicitly specified. That was it is not a breaking change to the API but the frontend can opt into the pagination. It also allows us to merge this already without the frontend supporting the pagination yet.

there seems to be multiple APIs serving versions (e.g. also /crates/:crate_id returns these infos)

Hmm, yeah that makes it more complicated. I think it's fine if we start with just that main endpoint and potentially migrate the others later if needed.

data is sorted by semver in code, this obviously isn't compatible with pagination, so I've added query sort by created_at to mitigate the problem, but I'm quite not sure about it

that is unfortunate but I'm not sure I have a better solution for that right now either. I'm wondering how efficient it would be to first only load the list of version numbers for the crate, order them in rust, paginate them and the load the details. But I guess that might be incompatible with how we want the seek-based pagination to work :-/

I guess technically we could implement a Postgres extension that allows us to order by semver inside the database, though that might be a bit complicated 😅

Still haven't checked if it need some edits frontend-side

It will need some changes, but they probably could be done separately if we modify the API in a non-breaking way.

[Turbo87]

There is also https://github.com/theory/pg-semver, apparently, but I don't know if that works well and is supported by Heroku Postgres. Might be worth trying out though.

[nappa85]

There is also https://github.com/theory/pg-semver, apparently, but I don't know if that works well and is supported by Heroku Postgres. Might be worth trying out though.

As far as I know (source: https://help.heroku.com/7KM0BSLY/how-do-i-add-a-postgres-extension-to-my-database) it's not possible to install extensions on Heroku's Postgres, you can only use the preinstalled ones

[nappa85]

@Turbo87 I don't know if I dared too much here, I haven't seen a real motivation for that mutable reference, and in facts the rest of the code is untouched

[Turbo87]

this seems like a useful change, but it would be best if such refactorings were kept out of this PR for a functional change. (see chapter 6 of https://mtlynch.io/code-review-love/ for a much better explanation :D)

[bors]

☔ The latest upstream changes (presumably b0bb138) made this pull request unmergeable. Please resolve the merge conflicts.

[nappa85]

Something nasty happened during the rebase, probably better restart from scratch...

[bors]

☔ The latest upstream changes (presumably #4892) made this pull request unmergeable. Please resolve the merge conflicts.

[Turbo87]

closing in favor of #8037