API section #139
Merged
API section #139
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
API - Intro chapter
API - JSON:API chapter
API - Authentication chapter
API - Documentation chapter
API - Versioning chapter
API - Pagination chapter
API - CORS chapter
jerko-culina
approved these changes
Sep 24, 2021
|
|
||
| Since this type of pagination allows clients to request any page, it is usually represented in the UI with a paginator where you can select a page (e.g. `<- 2 3 4 5 6 ->`). If this is the kind of UI you're implementing the pagination for, then the page-based type is the right choice. | ||
|
|
||
| This type is also popular because it's easy to implement using SQL's `OFFSET` clause, so you may often hear it being referred to as offset-based pagination. `page[size]=50&page[number]=3` simply translates to `LIMIT 50 OFFSET 50 * (3 - 1) => LIMIT 50 OFFSET 100` in SQL. However, offset-based pagination has a negative side. The clause requires scanning _all_ rows included by the offset value, which is inefficient for large offsets and causes performance to suffer the more pages you have (e.g. page 100 is slower to fetch than page 1). If you don't have to paginate many records, then it's not that much of an issue. |
There was a problem hiding this comment.
The clause requires scanning all rows included by the offset value, which is inefficient for large offsets and causes performance to suffer the more pages you have
- I am not sure that this is completely true, at least in the PostgreSQL
- As far as I know, there are ways how we can arrange indexes in PostgreSQL so that they can be used for OFFSET
- Another problem is LIMIT, you need to use SORT BY for it, and also as far as I know we can use indexes so that it does not have to sort the whole table
There was a problem hiding this comment.
I'll open this as a task so we can discuss it 🙂
AlexDrumia
reviewed
Sep 27, 2021
AlexDrumia
reviewed
Sep 27, 2021
AlexDrumia
reviewed
Sep 27, 2021
AlexDrumia
reviewed
Sep 27, 2021
AlexDrumia
reviewed
Sep 27, 2021
AlexDrumia
reviewed
Sep 27, 2021
AlexDrumia
suggested changes
Sep 28, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Task: #356
Aim
Branch that contains all changes for the API section.
Related private repo PR: https://github.com/infinum/rails-handbook-private/pull/23