Server-side $resource pagination versus client-side limitTo for large AngularJS datasets

Answer first

For a large dataset in AngularJS 1.x, bound the query at the server and return only the requested page. Use client-side limitTo only when the full collection is already small enough to load and digest safely.

Expose the total count from the backend for UI controls via an HTTP header such as X-Total-Count or an envelope body {items:[], total:N} handled with $resource isArray:false and transformResponse. There is no universal row count where client-side digest cost outweighs server round-trip latency; start server-side around a few hundred rows or when payload size and binding complexity make the first load and digest noticeable. Measure in your target browser and network.

Confirmed facts

• AngularJS 1.x has no built-in pagination service. limitTo filter exists since 1.2 and only restricts what is rendered, not what is loaded.
• $resource query() defaults to isArray:true. An envelope object response must be handled with isArray:false, transformResponse, or header-based total count to avoid deserialization errors.
• limitTo does not remove the cost of the full array. The full collection remains in scope and memory and the filter can re-run during digests.
• Server-side paging requires a stable backend sort with a unique tie-breaker, otherwise pages can repeat or skip rows when sorted columns contain ties.

Likely explanation and practical steps

Initial fetch strategy

Prefer server-side paging for large datasets. Have $resource send page/size or offset/limit and return only that page. This bounds payload and browser memory.

app.factory('Items', ['$resource', function($resource){
  return $resource('/api/items', {}, {
    page: {
      method:'GET',
      params:{page:'@page', pageSize:'@pageSize'},
      isArray:false
    }
  });
}]);

Use track by a unique id in ng-repeat and keep page size small to reduce DOM and digest cost regardless of strategy.

Total count for UI controls

Return the count that reflects the same filter, sort, page and size parameters as the items.

• Header option: backend sets X-Total-Count. Read it in transformResponse from headers.
• Envelope option: backend returns {items:[...], total:N}. Use isArray:false and map response in transformResponse to expose items and total to the controller.

The count must be consistent with the applied filters; otherwise pagination controls will be incorrect.

When client-side limitTo becomes costly

No fixed threshold exists. The crossover depends on item size, binding complexity, client CPU, and round-trip time. As a rule of thumb, start server-side around a few hundred rows or when full payload is large relative to network latency.

Verification steps for this case:

1. Implement a $resource method with params {page, pageSize} and confirm backend returns only that page plus total count header or envelope field.
2. Measure initial load transfer time, time-to-first-render, and longest frame/digest for full-load plus limitTo versus server-side page load at candidate row counts.
3. Vary page size and sort ties to verify pages do not repeat or skip rows and total count stays consistent with filters.

Assumption and uncertainty: AngularJS 1.x is end-of-life; behavior is based on well-established 1.x semantics. Exact safe row count cannot be inferred without measurement in your target browser and network conditions. Client-side sorting/filtering before limitTo requires the full dataset in memory and can invalidate pagination if backend data changes between operations.

One missing diagnostic detail that would change the recommendation: approximate row count and average item payload size, plus the complexity of bindings per row in your ng-repeat. With that, a more specific threshold can be estimated.