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
Search: implement stable API #7255
Conversation
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 looks great. I realize a lot of my comments are on code that was already there, but I think trying to clean this up where possible to make it a bit nicer to read is useful. I don't want to do a lot more refactoring, but at least cleaning up some of the magic functional logic and data structures would be
Co-authored-by: Eric Holscher <25510+ericholscher@users.noreply.github.com>
…s.org into search-stable-api
Co-authored-by: Eric Holscher <25510+ericholscher@users.noreply.github.com>
…s.org into search-stable-api
I have refactored some bits and used another endpoint for the new search response (we will remove/stop supporting the old endpoint, right?). I want to test this a little more next week in case the refactor broke something. |
Also, reminder for myself to update the search extension too https://github.com/readthedocs/readthedocs-sphinx-search/pull/55/files |
Ok, nothing broke, this is ready for review again. |
.. warning:: | ||
|
||
This API isn't stable yet, some small things may change in the future. |
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'm leaving this warning since the response will change when we start returning relative paths
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 wonder if we should do the relative path work in another PR after merging this one, before shipping it? Seems nice to get it all done together if possible.
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.
Sure, I can start working in another PR
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.
These changes look good -- I think this will be a good step forward
295d684
to
f46dd4f
Compare
How is this going to be released without breaking search for cached versions?
Requests with the
new-api=true
param will get the new api, requests that don't set that param will get the old api.This is temporary, once we release and browsers fetch the new js (1 or 2 weeks?), we can always default to the new api and delete the old code. Also, having the additional query string will prevent from fetching the results from the cache.
Also, I we can hold off on the docs till we make the change if we want.
Closes #5821
Closes #6341
todo