Feature Request: Ability to take params from hash instead of query string to optimize CDN caching

[patricknelson]

Hi! I work on a high traffic website that utilizes a CDN to cache pages generated by our server. This caching includes both the host/parent page and importantly the child page hosted in the <iframe> that pym.js is dutifully embedding for us.

Problem: I noticed that while pym works beautifully out of the box, it still utilizes parameters in the URL such as initialWidth which vary dramatically on a per-client basis. Unfortunately, with most CDNs, this type of parameter will "bust" the cache for the child page in the URL , even though content itself really doesn't vary at all. This results in additional unnecessary load on servers even though the same exact content is served to all devices of all screen sizes/resolutions and etc. While it may be possible to bypass at the CDN level with special rules, this is sometimes very difficult and time consuming to do (especially in larger companies with separate teams).

Proposal: Add new configuration option such as config.hashparams (defaults to false) which shifts parameters like so:

• URL based: child.html?initialWidth=1234&childId=pym-0-abcdef&parentTitle=My%20Parent&parentUrl=https%3A%2F%2Fexample.com
• Hash based: child.html#initialWidth=1234&childId=pym-0-abcdef&parentTitle=My%20Parent&parentUrl=https%3A%2F%2Fexample.com

Considerations: Since this is a new parameter that defaults to false and must be enabled to change functionality, it should be relatively low risk. However, this should throw an error if it detects that the child URL already contains a hash, since that functionality isn't well defined and could conflict (i.e. it may not be possible to merge this app-specific use with the use implemented by the child page). In those scenarios, if a hash is already in use by the child, the developer should be warned with an error in the console so they can resolve the conflict.

The advantage here is that at least this application can leverage it for this if it's not already in use and gain the advantage of not busting URL-keyed CDN caches on high traffic pages. 😊

[thomaswilburn]

Hi Patrick, while I'm no longer at NPR, I was the senior developer there from 2018-2021, and as far as I'm aware, there is not active development on Pym. As a result, unfortunately, it's unlikely that this would be added. You might want to look instead at https://github.com/nprapps/sidechain, the successor to Pym, which does not by default add parameters to the guest frame (unless you use a loader script to do so for yourself) and is compatible with Pym on both the guest and host side of the frame.

[patricknelson]

Ah, ok thanks for sharing that @thomaswilburn! I'll have to check that out. If this works fine out of the box without needing params, then in our case, we'll likely do just fine since that's what we're doing right now (very minimal config).

Sadly, the main Pym landing page makes no mention at all of Sidechain. Maybe the action here is to flag the library as deprecated to point users to the new app? 🤔

We happened to be using Pym from the ancient days of yore (circa ~2015 or so?) so I just carried on with the "updated" version of the lib when we enhanced our site (apparently from ~2018). So, it looked a bit dated, but seemed mature enough to not need changes, so there wasn't any indication that a successor existed. Thankfully migration on our end might not be too difficult.