It’s certainly been my experience that page sizes should be bigger than you initially expect. Paginated endpoints are typically iterated all the way through meaning you’re going to return that data anyway. May as well save the additional overhead from multiple requests.
Not implementing pagination at the outset can be problematic, however. If you later want to paginate data (e.g. if the size of your data grows) then it’s going to be a breaking change to implement that later. Big page sizes but with pagination can be a reasonable balance.
I had a beloved F91W that I used for years. One day, when surfing in Morocco, it gave out and the screen became foggy before showing me an error code and never recovering. I guess I should have gone deeper.
Although I'm only on job three and have not had that much involvement with open source, I think my current employer (Attio) has one of the best codebases I've seen.
Qualitatively, I experience this in a few ways:
* Codebase quality improves over time, even as codebase and team size rapidly increase
* Everything is easy to find. Sub-packages are well-organised. Files are easy to search for
* Scaling is now essentially solved and engineers can put 90% of their time into feature-focused work instead of load concerns
I think there are a few reasons for this:
* We have standard patterns for our common use cases
* Our hiring bar is high and everyone is expected to improve code quality over time
* Critical engineering decisions have been consistently well-made. For example, we are very happy to have chosen our current DB architecture, avoided GraphQL and used Rust for some performance-critical areas
* A TypeScript monorepo means code quality spreads across web/mobile/backend
* Doing good migrations has become a core competency. Old systems get migrated out and replaced by better, newer ones
* GCP makes infra easy
* All the standard best practices: code review, appropriate unit testing, feature flagging, ...
Of course, there are still some holes. We have one or two dark forest features that will eventually need refactoring/rebuilding; testing needs a little more work. But overall, I'm confident these things will get fixed and the trajectory is very good.
Not implementing pagination at the outset can be problematic, however. If you later want to paginate data (e.g. if the size of your data grows) then it’s going to be a breaking change to implement that later. Big page sizes but with pagination can be a reasonable balance.