Change Details

This task is about implementing a minimal service that essentially composes an HTTP response based on multiple other resources that are themselves more cacheable and less variable. Initial version requirements: * **High-throughout**. Suitable for handling traffic at the edge, essentially doing only HTTP and string manipulation. * **Request routing**. * **HTML Templating**. Fetch, precompile and cache templates - presumably Mustache. * **Streamable**. Must implement template handling so flushing starts early and continues progressively. * **Export as ServiceWorker**. Add an endpoint that exports the router and configured RequeestHandler subclasses to the client. Related: * <https://jakearchibald.com/2016/streaming-template-literals/> * <https://github.com/digitaldesignlabs/talisman> * <https://github.com/wikimedia/elematch> It should probably use service-runner and not be specific to MediaWiki in anyway. We can later use this library in a MediaWiki-specific installation that extends certain base classes and provides relevant configuration. Due to unsolved technical debt (see T111588#2416137), I suggest the initial implementation is used for a less complicated use case. The Wikipedia.org portal, for example, which needs localisation in a performant way. Currently done client-side with XHR and causes a FOUC. Outline for request-response life cycle: * Route. Find the relevant route and and off to associated response handler (e.g. "mediawiki-pageview", "wikipedia-portal", etc.). * Handle. Handler extract information from request url and headers and make fetches from cache or backend (Page, Skin template, misc resources). * Respond. HTML Template is invoked. Headers and first bytes are sent (allowing browser to start requesting other sub resources). Progressively continues to render based on decisions being made in the HTML template syntax with the given data properties.

This task is about implementing a minimal service that essentially composes an HTTP response based on multiple other resources that are themselves more cacheable and less variable. Initial version requirements: * **High-throughout**. Suitable for handling traffic at the edge, essentially doing only HTTP and string manipulation. * **Request routing**. * **HTML Templating**. Fetch, precompile and cache templates - presumably Mustache. * **Streamable**. Must implement template handling so flushing starts early and continues progressively. * **Export as ServiceWorker**. Add an endpoint that exports a JavaScript program compatible with a ServiceWorker that contains all the utilities (elematch, mustache etc.), Router, RequestHandler, and the current install's router configuration and custom RequestHandlers. Related: * <https://jakearchibald.com/2016/streaming-template-literals/> * <https://github.com/digitaldesignlabs/talisman> * <https://github.com/wikimedia/elematch> It should probably use service-runner and not be specific to MediaWiki in anyway. We can later use this library in a MediaWiki-specific installation that extends certain base classes and provides relevant configuration. Due to unsolved technical debt (see T111588#2416137), I suggest the initial implementation is used for a less complicated use case. The Wikipedia.org portal, for example, which needs localisation in a performant way. Currently done client-side with XHR and causes a FOUC. Outline for request-response life cycle: * Route. Find the relevant route and and off to associated response handler (e.g. "mediawiki-pageview", "wikipedia-portal", etc.). * Handle. Handler extract information from request url and headers and make fetches from cache or backend (Page, Skin template, misc resources). * Respond. HTML Template is invoked. Headers and first bytes are sent (allowing browser to start requesting other sub resources). Progressively continues to render based on decisions being made in the HTML template syntax with the given data properties.

This task is about implementing a minimal service that essentially composes an HTTP response based on multiple other resources that are themselves more cacheable and less variable. Initial version requirements: * **High-throughout**. Suitable for handling traffic at the edge, essentially doing only HTTP and string manipulation. * **Request routing**. * **HTML Templating**. Fetch, precompile and cache templates - presumably Mustache. * **Streamable**. Must implement template handling so flushing starts early and continues progressively. * **Export as ServiceWorker**. Add an endpoint that exports the router and configured RequeestHandler subclasses to the clienta JavaScript program compatible with a ServiceWorker that contains all the utilities (elematch, mustache etc.), Router, RequestHandler, and the current install's router configuration and custom RequestHandlers. Related: * <https://jakearchibald.com/2016/streaming-template-literals/> * <https://github.com/digitaldesignlabs/talisman> * <https://github.com/wikimedia/elematch> It should probably use service-runner and not be specific to MediaWiki in anyway. We can later use this library in a MediaWiki-specific installation that extends certain base classes and provides relevant configuration. Due to unsolved technical debt (see T111588#2416137), I suggest the initial implementation is used for a less complicated use case. The Wikipedia.org portal, for example, which needs localisation in a performant way. Currently done client-side with XHR and causes a FOUC. Outline for request-response life cycle: * Route. Find the relevant route and and off to associated response handler (e.g. "mediawiki-pageview", "wikipedia-portal", etc.). * Handle. Handler extract information from request url and headers and make fetches from cache or backend (Page, Skin template, misc resources). * Respond. HTML Template is invoked. Headers and first bytes are sent (allowing browser to start requesting other sub resources). Progressively continues to render based on decisions being made in the HTML template syntax with the given data properties.