Are you referring to:
https://github.com/tiangolo/full-stack-fastapi-postgresql/blob/490c554e23343eec0736b06e59b2108fdd057fdc/%7B%7Bcookiecutter.project_slug%7D%7D/frontend/src/views/main/admin/AdminUsers.vue#L10-L26
Because I can't find a place where the 100 is hardcoded 🧐

Are you referring to:

https://github.com/tiangolo/full-stack-fastapi-postgresql/blob/490c554e23343eec0736b06e59b2108fdd057fdc/%7B%7Bcookiecutter.project_slug%7D%7D/frontend/src/views/main/admin/AdminUsers.vue#L10-L26

Because I can't find a place where the 100 is hardcoded 🧐

Hardcoding is maybe the wrong wording but the effect is the same since the default limit is 100 users.

Well run the test suite a couple of times and you'll have a few hundred users. At this point you'll see that the users view only loads /users with default parameters which is limited to the 100 first in the backend, and does not move the start forward when paginating. Thus making some users unreachable from UI at this point.

In my application I've added a /meta route on all collection resources which returns {total_count: x}, which I then use for pagination.

I think the default values are some sort of security mechanism, so you don't access all data by accident which might result in very long loading times on the front- and backend.

You can always call the api with those values set or even add the logic to query all if -1 is given.
You could change this:
https://github.com/tiangolo/full-stack-fastapi-postgresql/blob/490c554e23343eec0736b06e59b2108fdd057fdc/%7B%7Bcookiecutter.project_slug%7D%7D/frontend/src/api.ts#L27-L29

to that:

async getUsers(token: string, userId: number, skip?: number, limit?: number) {
    return axios.get<IUserProfile[]>(`${apiUrl}/api/v1/users/`, {
      params: {
        ...(skip ? {skip: skip} : {}),
        ...(limit ? {limit: limit} : {}),
      },
      headers: {
        Authorization: `Bearer ${token}`,
      },
    });
  },

And in the backend replace this:
https://github.com/tiangolo/full-stack-fastapi-postgresql/blob/490c554e23343eec0736b06e59b2108fdd057fdc/%7B%7Bcookiecutter.project_slug%7D%7D/backend/app/app/crud/base.py#L29-L32

with:

    def get_multi(
        self, db: Session, *, skip: int = 0, limit: int = 100
    ) -> List[ModelType]:
        if limit == -1:
            return db.query(self.model).offset(skip).all()
        return db.query(self.model).offset(skip).limit(limit).all()

In theory you should now be able to query all users by calling api.getUsers("token", 0, -1).

Anyway, I think this behavior is wanted and in the most cases it is safer to use it with skip and limit. If you want to support querying all add the -1 flag and you will still benefit of the limits. Maybe you want to query only 10 later on and only load more when the user clicks on next or somehting.

I think you misunderstood me.

I understand that 100 is the default value and the reasoning behind that, I don't want us to lift that limit.

What I'm proposing is simply to allow us to fetch the next 100 from the ui, by going to the next page. In my application I solve the by fetching the next N entries when going to the next page, where N is number of visible entries on the current page. This is a frontend change and doesn't require any changes to the backend, unless we want to be able to get the "max-page" which is more nice to have.

Ohh 😂 I see. Now, that would be a nice addition I think, do you happen do have already such a code piece?

I've been using fastapi-pagination on a small project to extend endpoints with pagination functionality. On the frontend I'm using v-data-table and v-data-iterator components and their events/hooks to browse paginated endpoints.