You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, whenever anyone lands on the web page for a catalog record, the app requests the JSON record from the ODP and renders it onto an HTML template. But published records rarely change, and multiple hits on a given page typically get an identical response. Pages for records with many child DOI references require a noticeably time-consuming series of API calls in order to render child record titles. To mitigate, fetched titles are cached for a limited time in the app's Redis instance. This would all be unnecessary if pages were pre-rendered and updated periodically.
The proposal is to create a harvester to run at scheduled intervals (e.g. 1 hour after ODP publishing times) to render and save the HTML page for every record that has been added or modified since the last update, and to delete any page where the record has been retracted. The pages can be served statically by Nginx, with lightning fast page load times.
Note that this proposal affects only the catalog record detail pages, not the search interface or the display of search results.
The text was updated successfully, but these errors were encountered:
Currently, whenever anyone lands on the web page for a catalog record, the app requests the JSON record from the ODP and renders it onto an HTML template. But published records rarely change, and multiple hits on a given page typically get an identical response. Pages for records with many child DOI references require a noticeably time-consuming series of API calls in order to render child record titles. To mitigate, fetched titles are cached for a limited time in the app's Redis instance. This would all be unnecessary if pages were pre-rendered and updated periodically.
The proposal is to create a harvester to run at scheduled intervals (e.g. 1 hour after ODP publishing times) to render and save the HTML page for every record that has been added or modified since the last update, and to delete any page where the record has been retracted. The pages can be served statically by Nginx, with lightning fast page load times.
Note that this proposal affects only the catalog record detail pages, not the search interface or the display of search results.
The text was updated successfully, but these errors were encountered: