Remove .html from page endpoints.

[grosscol]

Problem

The endpoint url are terminated with .html extensions.

/region.html?variant_type=snv&chrom=11&start=5225000&stop=5229000

This is because of a limitation of webpack dev-server. It will currently serve these endpoints out with the mime-type application/octet-stream.

Serving the extension-less files on a production webserver as the correct 'text/html' mimetype is easy to accomplish.
It is making the development environment capable of doing this as well that is the blocker.

Exising research

This is occurring because the webpack dev-server's underlying package, express, uses a version of mime will provide a default mime-type when one is not deduced from the file extension. The RFC compliant behavior would be to not provide any mime-type in this case.

Webpack's dev-server via webpack-server-middleware is doing the the correct thing and not providing a default mime-type. Unfortunately, that makes it so express does.

Upstream Fix

The closest fix down in the stack is to allow webpack-server-middleware to be configured to emit a default mime type. Functionally, this would only cover files without extensions as there is existing configuration to add mime-type mappings for file extensions. Essentially, a PR to fulfill this feature request

Additionally the underlying express project could be updated to use a more recent version of mime and ensure that the default mime-type is none unless explicitly configured.

[abought]

Another option would be to have flask serve the HTML files as static assets, eg using X-SENDFILE support?

It sounds like in this mode, some UI routes would be defined in flask, others duplicated in multiple places across apache(? per-host?) / webpack dev server, and still others inside a vue router SPA someday (if the migration continues). Speaking from experience, "where is this feature implemented" is an awkward scavenger hunt, esp if it could lead to drift between dev and prod over time.

If consistency across routes is possible, it makes for a nicer dev experience. Webpack dev server does offer a way to proxy requests to the flask app as well, if you wanted the live dev environment to still look and act like a single unified app in prod.

[grosscol]

That's an interesting thought. Abandoning the webpack dev-server altogether until the issue is resolve upstream is viable. I don't think I'd go with flask and instead provide an apache or nginx config for serving out the built files.

I suspect the downside there is the loss of hot reload tooling, or having to build some custom tooling to get it working with a different webserver.

[abought]

There are a few ways to do this- some of which (via the proxy trick) allow you to get the best of both worlds. The custom tooling is minimal. These are so widely used that a lot of features are available out of box (check the manual, there's a lot in there).

(we use SPA + proxy to flask API in FIVEx, for example. Hot reload works fairly well in that scenario, still minimal custom webpack required)

But yeah, implementing routes as separate files.... it does run into basically this problem. I don't like a lot about SPAs, but architecturally, it's easier to pick clean lines of fragmentation than it is to deploy the app piecemeal.