su-fit-vut / kachna-online

Students' Club U Kachničky: Member's portal
MIT License
5 stars 5 forks source link

Paging #18

Open ondryaso opened 2 years ago

ondryaso commented 2 years ago

We need to add paging to some endpoints that can potentially return unbearable amounts of data at once.

Users: GET /users may return hundreds of users, paging is crucial here. \ Top priority

BoardGamesReservations: GET ​/boardGames​/reservations​/all could also get quite large over time. \ A bit lower priority than with users.

ClubState: GET /states is another candidate. However, right now I think that the maximum time range limitation should be enough. I expect around 80 states per month which is bearable. \ Low priority.

BoardGames: GET /boardGames might be a candidate for paging too but given the expected number of items there, I don't think it's currently necessary.

Events: GET /events should perform paging merely to be consistent with the other endpoints but given the expected amount of them and the existing time range limitation, I don't think these will ever be an issue.

RepeatingStates: There will be so few of these that paging is not necessary here.

FrNecas commented 2 years ago

Also related: reservations are currently sorted chronologically on frontend (see reservations.component.ts), this should probably be removed and moved to backend/somehow done during the pagination.