Allow resource types to include count

I think that it's interesting to be able to trigger counts per request.

I am confused by the strong feelings about where this feature should live (JSON API Extras). Having an extra module will have a negligible impact on performance, but it may be another concern.

I'm OK with that. Although I'm also interested in what is not working with the current solution.

This is how I understand this issue. Hopefully everyone finds this title clearer?

Although I'm also interested in what is not working with the current solution.

@jibran already explained that in the IS:

The biggest problem I have with this is once you enable count qurey it adds count to all collection responses which means two same queries on same run.

IOW: a performance problem.

I would personally be okay with this feature by the way; it'd just be another profile to document in #2955020: Spec Compliance: JSON API's profile/extention (Fancy Filters, Drupal sorting, Drupal pagination, relationship arity) needs to be explicitly communicated. It's very simple. Not obtrusive. And it'd help make jsonapi_extras even simpler (and remove the need for it in this particular use case).

Given the performance impact I prefer this to be a server setting.

Hrm… but right now that server setting is making every collection response slow. I think that's @jibran's complaint?

We could make it be a per resource type setting in jsonapi extras. My point is not to allow an ill intentioned anonymous user to add extra load, for this feature.

I understand that. But custom query strings always allow you to bypass Drupal's caches. This is a widely known weakness. So I'm not concerned about this TBH.

Well, it's not only that they bust cache, but that they now can trigger a (potentially heavy) database query for the count.

Yes. But they already can easily trigger much more expensive database queries by hitting a complex Views page while breaking the cache using a random query string.

You're right that it's desirable to avoid that cost. But I think you're not realizing how much bigger costs already exist aplenty elsewhere! 😭

We should strive to not make it worse, right?

In a separate topic, we have the chance to 4XX unknown query string parameters used for cache busting. Somehow I thought that was the case. If not, we can make that happen.

In a separate topic, we have the chance to 4XX unknown query string parameters used for cache busting.

What do you mean?

You'll always be able to bypass Page Cache. Technically, Dynamic Page Cache is already helping us with query string cache busting, since it explicitly varies by url.query_args:fields, url.query_args:filter, and so on. But you can still bypass even that by passing ?filter=RANDOM, because it's impossible for us to validate all possible values for those URL query args.

I'm going to let this issue rest; it's not important enough compared to other issues to be spending more time on this theoretical cache busting discussion.

I'm going to let this issue rest; it's not important enough compared to other issues to be spending more time on this theoretical cache busting discussion

I was trying to communicate that the concern is not (only) cache busting.

Well, it's not only that they bust cache, but that they now can trigger a (potentially heavy) database query for the count.

By making this setting server-side (per resource type, as opposed to globally like it is now in JSON API Extras) it would help mitigate this concern. This would be the decision of a site admin, not a (potentially) malicious user.

Maybe we can also consider white listing resource types that can use the ?count query string parameter.