While porting to the latests Prismic client for Javascript - I've found that the option apiDataTTL is no longer exposed.
The default TTL is 5 seconds which is great when optimizing for the freshest data - but I would like to spread out my CMS latency across a longer time period (60 seconds) - which doesn't seem to an unreasonable amount of caching in a production system.
In a production environment, we have seen regular times of 80ms to 200ms of latency from the initial API Data resolution. Which seems high for p50 scores. Are there alternative patterns that would allow for some flexibility on this TTL setting?
I need some more information about your use case, and some explication of what you mean by "but I would like to spread out my CMS latency across a longer time period (60 seconds)" would be appreciated.
What kind of content you are fetching would take 60 seconds to terminate,
This isn't the content fetching that I am worried about -- content has a very long TTL by your design.
It is the initial call to determine the current REF (https://.cdn.prismic.io/api/v2) - which internally is cached for 5 seconds. In the previous releases of the Prismic client - we could configure this to have a longer TTL via apiDataTTL option. Ideally, we would not see these calls on 90% of our traffic - a slightly longer TTL would accomplish this.
Thanks for the explanation, but unfortunately I am still not able to understand the use-case where extending the TTL would be useful for the /api endpoint.