As I mentioned in a comment which is part of the existing este.js deployment issue, we've implemented the application that couldn't be deployed as a node.js server-side app and este.js didn't provide the Part-of-Framework deployment option to deploy it as a static site sitting at the server that serves our backend written in a technology of one's choice (doesn't matter which one). Please note, we don't mind losing all the shiny isomorphic app advantages like the prerendered app returned as a part of the request's response at moment and we know este.js wasn't designed with that in mind. On the other hand este.js dev stack is really one of the best (if not the totally best) out there at the time of writing and that's why we'd like to stick with it.
So I have decided to make the neccessary changes to este.js core myself in our app directly and in a later stage as soon as everything is tested contribute it back to the community. Before diving deep into the details let me explain the deployment scenario first.
We're deploying the este.js app for a preview to GitHub Pages (Project Pages) which means it is served from a subfolder (e.g. http://companyX.github.io/project-name/). In production environment it will probably (TBD yet) live in a subfolder too and if not, it will be served by something like nginx statically.
Now talk a bit about key issues that stopped us from the immediate deployment:
- Serving the assets properly
- Getting the correct app's index.html (incl. the initial state and the empty app container)
- Base URI acknowledgement due to deployment to a subfolder
- a)
<base href="/project-name/" />
- b)
<Route handler={App} path="/project-name/">
We've resolved number 1 in a pretty straightforward and I would say elegant way (inspired by the great Ember.js btw) by using <base href="/" />
tag in src/server/frontend/html.react.js
file (line 23 of the included file). You can read more about base tag here but to sum up it instructs browser to prepend all the relative links with the value given by its href
attribute - and not only links in terms of a
tags, but also img
's src
attributes and others so it basically defines an application base URI - great that's exactly what we needed. Then we had to modify all the links and strip away the initial /
character (line 11 of the src/server/frontend/html.react.js
and line 59 of the src/server/frontend/render.js
. Neat. The assets are being server properly now. Let's go to the next point.
We haven't automated this one yet. We've manually downloaded the index.html
from the running este's node.js app with env. var NODE_ENV=production
and since then we're only updating the initial state as we are adding new state.
We haven't automated this one either. Point 3a is resolved as a side effect of not automating number 2 yet. So our index.html is fixed on the server and we have the correct base URI in place. Point 3b must be done manually before each production build and that's really a pain to do.
What we aim for is to find a proper solution to points 2, 3a and 3b in a way so it can be merged back to the origin repo. In order to do that I consider these things to be essential to get there:
We have to find a way of getting the complete bundle during the build incl. index.html containing empty app container. (it might as well be run by using optional build switch) - possibly as a webpack plugin that takes advantage of existing though slightly refactored version of src/server/frontend/render.js
.
We have to inject an environment specific base URI to src/server/frontend/html.react.js
line 23 as well as src/client/routes.js
line 9 and src/server/main.js
line 15 by getting its value from a config file.