Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[F] Track CTA downloads in analytics #3797

Open
wants to merge 7 commits into
base: master
Choose a base branch
from
Open

[F] Track CTA downloads in analytics #3797

wants to merge 7 commits into from

Conversation

1aurend
Copy link
Contributor

@1aurend 1aurend commented Dec 20, 2024

No description provided.

@1aurend 1aurend marked this pull request as ready for review December 31, 2024 00:57
@1aurend 1aurend changed the title [F] FE for download analytics [F] Track CTA downloads in analytics Dec 31, 2024
Copy link
Contributor

@scryptmouse scryptmouse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small performance change, but otherwise looks fine on the API side!

@@ -99,6 +101,10 @@ def total_user_count
User.count
end

def total_download_count
Analytics::Event.where(name: DOWNLOAD_EVENT_NAMES).count
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to put a small cache on this to prevent a count scan from being executed on a potentially large table on each request. You'd just wrap the interior of the method body like this:

def total_download_count
  Rails.cache.fetch("statistics/total_download_count", expires_in: 5.minutes) do
    Analytics::Event.where(name: DOWNLOAD_EVENT_NAMES).count
  end
end

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. The whole request is also cached for longer:

  def show
    expires_in 3.hours, public: true
    render_single_resource Statistics.new,
                           serializer: ::V1::StatisticsSerializer,
                           location: "[:api, :v1, :statistics]"
  end

Should we adjust the 3 hour timeline at all? It seems reasonable for most cases, but if anyone is testing this on Edge, it's a long wait.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ope, was not aware of that. I would reduce it to 10 minutes. That only sets cache headers, which is easily bypassed by direct API access, but three hours seems excessive to me. We don't want these counts to run on every request, but a bunch every 10 minutes should be fine.

Given that in the request, I'd go ahead and ignore the rails.cache.fetch I advised above, since I wasn't looking at the whole class in context, really, and we'll improve the caching on this in another pass sometime in the future. Bigger scope than this, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants