-
-
Notifications
You must be signed in to change notification settings - Fork 275
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
feat(browseRequests): add browse endpoints with test and documentation in progress #297
Conversation
Hi @MonkeyDo, |
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 to see you start with the tests!
Looking at your proposal document, there are linked entities in your tests that weren't originally planned. For example, /author?publisher=…
.
I think for now you should limit to the planned links, and maybe think about adding other ones after the GSOC project.
For reference, here is what was originally planned:
<ENTITY> <LINKED_ENTITY>
/work edition, author
/edition work, author, edition-group, publisher
/edition-group edition, author
/author work, edition
/publisher edition, work
Hi @MonkeyDo |
Hi @MonkeyDo, |
@MonkeyDo Hi, |
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 glad to see you making good progress!
We're just around the corner from the deadline, and at that pace I think you'll make it!
Let me know if you have any questions regarding the feedback below.
src/api/routes.js
Outdated
* sortName: | ||
* type: string | ||
* example: 'Heinlein, Robert A.' | ||
* example: '<Sort name of enity>' |
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.
enity -> entity
src/api/routes/author.js
Outdated
); | ||
return res.status(200).send({ | ||
bbid: req.query.bbid, | ||
relatedAuthors: authorRelationshipList |
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.
Considering we are choosing to allow only one type of related entity at a time, would it be simpler for users to only have a related
or relatedEntities
property for all browse endpoints results, instead of a different one for each endpoint (relatedAuthors
, relatedWorks
, …) ?
What do you think?
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.
it gives the clarity on response.
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 see your point.
I would then suggest rolling back to what you originally had in the tests and proposal, and removing the related
part to have the response structure be {bbid:…, authors:[…]}
.
@MonkeyDo Hi! |
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.
The test{Entity}BrowseRequest
helpers don't currently allow you to test if the filters are working or not.
I would like to see less tests (I don't think there is any use in testing each filter-entity combination), but three tests specifically designed to ensure that each filter works, and that they work combined.
This will require a bit of rewrite. You'll need to set up the necessary works of different types and languages, and ensure that for each filter and for combined filters:
• you get 2 results if calling without the filter, and only one result with the filter
• without filter, there are different types/languages, and only one type if with the filter
That way we'll be sure that we don't break the filters mechanism in the future, rather that just testing that the query parameters are accepted.
This will ned to be done for each entity, as the filtering function is different for each.
@MonkeyDo |
Hi @endurance21! The API has lookup endpoints and browse endpoints. I think the best way to get started on it would be to do a PR review yourself, meaning reading through this PR code and pointing out anything that looks incorrect or could be improved upon After that, we can take it from there and I will do another full review with a view to getting this PR merged :) Don't hesitate if you have questions! |
@MonkeyDo |
I forgot some useful details you can find here: https://github.com/bookbrainz/bookbrainz-site#running-the-api |
576fb17
to
41b3ee1
Compare
No, we want people to fetch that —possibly beforehand— with |
@MonkeyDo Have a look at this when you're free :) |
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 is going really well, nice work !
It's really nice to see you're now quite comfortable with the testing framework, and thinking about what tests to write.
The route docs (inline swagger docs) still need a bit of love to match what's actually accepted for each browse endpoint (the accepted parameters and summaries don't match what's in the code).
On a more general note, I'm having serious second thought's about returning 406 errors when passed an invalid BBID. I think I was the one to decide that way back when last year, and it was probably a mistake.
406 Not Acceptable
This response is sent when the web server, after performing server-driven content negotiation, doesn't find any content that conforms to the criteria given by the user agent.
That doesn't seem adapted at all :/
I think instead a 400 should be returned. Along with the existing error message ('BBID is not valid uuid') I think that's clear enough.
The error code will need changing in the makeEntityLoader
helper, in the route documentation and route tests.
Aaah, This makes sense now. I was wondering why we did 400 error for this invalid-bbid-pr and 406 here. |
reduce the number of entities created while testing(5->2)
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.
Looking good !
Refactored to avoid fetching the entity twice. In the middleware to load the entity, ensure we're loading extra related elements that are not simple relationships
Both in Lookup request results and browse request filter parameters
And clean up language_set table in truncate helper
🎉 |
Problem
Implementation of Browse endpoints.
Solution
Start writing tests for those endpoints
Areas of Impact