One script that contains everything and will contain all future features

[metmarkosaric]

"Could we have a script that contains everything and will contain all future features? That way I can have all the features without re-deploying, as I wouldn't mind the extra 50kb"

(request via Twitter)

[ukutaht]

The intention behind our design is to push people towards lighter websites so they don't load dead weight on their pages. However, if having to re-deploy is too much of a tradeoff for some people, I'm OK offering this option.

[Vigasaurus]

I don't think this needs to be all that novel, we can just have a plausible.featured.js or similar for a fully-featured script that always aliases to the script with all types. I don't think this is common enough nor that important a use case to engineer it that much.

If all we're trying to allow is people to limit redeploys and have access to all features, this imo is the simplest and most future proof method.

[ukutaht]

Yeah I was trying to come up with a way to still load features conditionally but without having to re-deploy the script. This is normally solved by a 2-phase load - first the tag manager and then the actual tag with the features you need.

I agree that providing a full-featured script would be an easy fix for now

[Vigasaurus]

Yeah that makes sense.

That'd definitely be cool in the long term; maybe that could be something planned out in the custom domain rewrite - have a set of checkboxes in the site settings, and then let everyone load a plausible.js, but then the custom domain controller keeps track of the currently selected options for any site that has a custom domain, and serves the appropriate script over the CDN as necessary. This definitely brings up caching/invalidation issues on the CDN for selected options, how to sync the postgres options to the custom domain handler, and how to handle this same thing on first-party connections, since there's no way of knowing the associated site ID from just the request (that I know of, at least). Hard part is obviously keeping the serving fast and not having to hit postgres before responding.
Tricky, for sure.

[ukutaht]

Hmmm maybe we could use some of the modern CDN/edge storage and worker infrastructure. We could store script config for each site in our postgres database and sync it to a distibuted KV store on the CDN (Cloudflare, Fastly, Bunny have these offerings). Then the edge worker could serve the correct script for the given site depending on what the distributed store says.

You're right in that currently the HTTP request to load the script initally does not contain enough information to determine what site is loading the script. So we would need to change how the script is loaded to also include the site_id somehow. Could be as easy as loading /js/plausible.js?site_id=the-id-of-the-site. I know for a fact that edge workers can inspect query params and alter the response based on it.

This all would load the appropriate script in one roundtrip without causing extra HTTP requests to the CDN servers or requiring a deploy from the user.

Cache invalidation is a huge issue here of course. Fortunately these platforms allow manual cache purging via the API. So we could manually invalidate the cache every time we update script options for a given site.

Downsides of this approach: it's an area where self-hosters and the Cloud installation will probably diverge quite a bit. Most people won't be running the same CDN as us. Or willing to pay for external edge storage/computing. Of course all of this will incur a cost from the CDN service provider as well. It's cheaper for us to require a re-deploy so we don't need to compute as much on the edge servers.

[Vigasaurus]

That's true. Maybe self hosted can take a more straightforward and not very horizontally scaling approach of storing site options in-memory, and serving /plausible.js through elixir and redirecting/aliasing as necessary. The same could work for the first-party, but of course that's terrible at scale, and sending it off to the CDN is 1000% better.