Static Shock supports some expensive behaviors. For example, Static Shock talks to the Pub and GitHub APIs in a couple of plugins. Static Shock is likely to increase the variety of expensive behaviors in the future.
These behaviors might need to run multiple times, but they certainly don't need to run every time the user makes a content change during development. We're currently wasting a lot of time and networking by constantly hitting the APIs.
Introduce a caching mechanism through which end-user code, as well as plugin code, can store information locally to avoid hitting the API.
Consider the possible caching policies. An obvious cache expiration policy based on the amount of time since the last call probably makes sense for many plugins. It's also reasonable to expect that for a given input, a plugin's value might never change, and therefore the caching policy would be something like "only re-run the data loading when the input request is different than before".
Static Shock supports some expensive behaviors. For example, Static Shock talks to the Pub and GitHub APIs in a couple of plugins. Static Shock is likely to increase the variety of expensive behaviors in the future.
These behaviors might need to run multiple times, but they certainly don't need to run every time the user makes a content change during development. We're currently wasting a lot of time and networking by constantly hitting the APIs.
Introduce a caching mechanism through which end-user code, as well as plugin code, can store information locally to avoid hitting the API.
Consider the possible caching policies. An obvious cache expiration policy based on the amount of time since the last call probably makes sense for many plugins. It's also reasonable to expect that for a given input, a plugin's value might never change, and therefore the caching policy would be something like "only re-run the data loading when the input request is different than before".