URL rewriting for assets: let's stop doing it ...

[rufuspollock]

Right now an assets e.g. images, pdfs etc will have their location rewritten in the frontend. e.g.

/assets/open-source-software-government-and-civic-tech.pdf

Will end up at

/_r/-/assets/open-source-software-government-and-civic-tech.pdf

I think this came from trying to deal with resources in data packages for datahub originally where we want a "permalink". But this doesn't make a lot of sense to me now (i think there was some idea at the time, maybe, that e.g. datahub.io/@xxx/mysite/data.csv would show a presentation of the data.csv e.g. a nice table page but not display the raw data.csv itself e.g. think how github displays files in its browser tree. However, i now think this is the wrong mental model for flowershow and complicates how things work)

Recommendation: switch back to have normal rendering with no url rewriting

How? [Hypothesis] catch these assets links and redirect them to raw storage e.g. everything with a .xxx extension is redirected to raw and everything without an extension is assumed to be a page that we should render.

Aside: This would actually be cool because it would work for markdown etc too e.g. going go mysite/abc.md would redirect to the raw markdown 🎉

Analysis

why do it? 👍

• makes our middleware really simple and reliable: everything at /_r/* is an asset and therefore rendered differently.
• we can create a special display page for the asset e.g. if a pdf we can create a nice rendering (perhaps still with the navbar and footer etc)

why not 👎

• Breaks simple mental model of user: urls at X end up at X on published site. for raw assets
• Breaks link using classic markdown link syntax (only [[...] links are getting rewritten to these new asset paths)
• It will also break links in more complex components that use relative or absolute links. We now need to rewrite internal links everywhere complicating the developer experience.

Conclusion

Overall i think this is bad UX / DX. If there is an easy way to catch these links and redirect them to raw storage then we should do it (the easiest way is just everything with a .xxx extension is redirected to raw and everything without an extension is assumed to be a page that we should render. This would actually be cool because it would work for markdown etc too e.g. going go mysite/abc.md would redirect to the raw markdown 🎉

Potential complications

• what happens if there are assets without extensions e.g. you can have an image with an extension (if you set the content-type right). But i don't how this would happen in the world of flowershow. so not an issue IMO
• if we do want a nice rendering for e.g. a data file where would it go? one idea was to have e.g. data.csv.md file created but then that would clash in url terms (we'd have both raw asset at data.csv url and data.csv markdown file rendering). All that said, if/when this becomes wanted we can work something out e.g. we could have some convention of e.g. /_v/{path-to-asset} generating the nice view version or data.csv?view=true or whatever.