Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Hosting: manual integrations via build contract #10127
Hosting: manual integrations via build contract #10127
Changes from 5 commits
5b28071
e18b40f
7754d5f
2925ed9
3385649
1e391b8
6afca0b
7ce98a4
3ca96ec
f4f1268
a596512
33fdb2b
4ced5c3
ea2af4c
79b7393
17effaf
2b9cdbf
0116f41
d5130cc
761e3b6
bd9f70e
842a228
2ad30cc
89662fa
f83eee6
d14115a
067bb4c
17c1af3
53366aa
0f89186
48de597
4b05e77
e90af75
364de9c
c1cf8cb
3930915
2d7b6fe
ab43635
85ab2e7
3439e24
6154c7f
0e8f245
a6c5977
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
We should use
readthedocs.core.utils.filesystem.safe_open
hereThere 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.
It seems like we're re-creating the footer API, but with JSON instead of HTML. That seems reasonable, but I do think we'll want to think more about what this API is returning.
It seems like we actually want the client to be able to tell us exactly what data points they want? Something similar to what we're doing with apiv3 with the
expand
andfields
parameters? That way we give the caller control over how much data they want...That might be an over-optimization at this stage, but I think we want to design this with expandability and performance in mind.
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.
Yes. This is one part of the design decisions I mentioned we have to sit down, talk together, think about and decide what's the best structure.
This is a good point to start considering and thinking about, yeah. However, I don't think we will require that complexity because:
Project
andProject.versions(active=True)
)non_latest_version_warning
is disabled, we don't calculate/query nor return the list of active versions this feature consumes in the client.In any case, I think we will arrive at the best answer by exploration, experimentation and brainstorming. Also, once we deploy this, we will have some data in NR to know how much time this endpoint takes on a real production db.
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.
Yea, I don't think the performance of this approach is inherently bad, but more that we might want to make this look more like an API for additional UX options in the future. No user will expect passing GET args to a
.json
file. However, if the file doesn't grow too large, always returning all of it too bad. But I do expect we'll feel constrained by the design in the future, as we want to make this endpoint smarter, so starting with an API instead of a JSON file seems like the proper design to me.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.
To be clear, I'm fine shipping this as a test for now.
But I do think over time if this is the "one endpoint to get all the data you need in the page", there will be demands on this functionality that are resource intensive, vary by user, etc. That is where we'll start to get value from the API approach.
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.
Good point about the .json name in the URL endpoint. We should definitely change that as first step.
I will think a little more about the expand argument. I don't have a strong opinion on that yet 😅
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.
When we get to discussing the API structure in the next phase, this would be a good conversation. This API could help us avoid APIv3 complexity.
Also on the difference between this and our API, would it make sense to use DRF APIv3 resources directly in the response here, or make this an APIv3 endpoint? This way weren't not making a 4th API version of sorts. The response for versions could be identical to the APIv3 response for versions as well.
We'll come back to the data security question around private projects/versions pretty quick here, but we need to already for this API endpoint and private projects.