Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Cap pagination page size with a sane maximum
Validate the pagination limit/take parameter with a reasonable maximum instead of allowing arbitrarily large page sizes.
Bad example
| 1 | export class PageFilterDto { |
| 2 | @IsOptional() |
| 3 | @Type(() => Number) |
| 4 | @IsInt() |
| 5 | @Min(1) |
| 6 | @Max(1000) |
| 7 | take?: number = 20; |
| 8 | } |
Explanation (EN)
A maximum of 1000 lets a single request fetch an enormous page. Large page sizes strain the database and serialization, and can be used to hammer the endpoint.
Objašnjenje (HR)
Maksimum od 1000 omogucava da jedan zahtjev dohvati ogromnu stranicu. Velike stranice opterecuju bazu i serijalizaciju te se mogu zloupotrijebiti za napad na endpoint.
Good example
| 1 | export class PageFilterDto { |
| 2 | @IsOptional() |
| 3 | @Type(() => Number) |
| 4 | @IsInt() |
| 5 | @Min(1) |
| 6 | @Max(100) |
| 7 | take?: number = 20; |
| 8 | } |
Explanation (EN)
A modest ceiling (e.g. 100) keeps responses bounded and predictable while still letting clients page efficiently. Clients fetch more by paging, not by inflating the limit.
Objašnjenje (HR)
Umjeren gornji limit (npr. 100) drzi odgovore ogranicenima i predvidljivima, a klijenti i dalje ucinkovito straniciraju. Vise podataka klijent dohvaca strancima, a ne napuhavanjem limita.
Exceptions / Tradeoffs (EN)
Internal/admin export endpoints may justify higher limits, but those should be explicit and ideally streamed rather than served as one large page.
Iznimke / Tradeoffi (HR)
Interni/admin export endpointi mogu opravdati vise limite, ali to treba biti eksplicitno i po mogucnosti streamano umjesto sluzeno kao jedna velika stranica.