Closed Marschelloss closed 8 years ago
For everybody who is searching to demo deploy:
Remove the dist
folder from the .gitignore-file. Run npm start deploy
to compile the app into dist
. Now you can deploy the folder to git/heroku/whatever.
Till now i wasnt able to fix my own error. I think it doesnt load some webpack middleware.
I am in the same boat. Could someone explain to me why the server that is bundled isnt production ready and what would constitute a server that is. For example if I were building a docker container to serve this why shouldnt I use the provided server? Is it security, performance, flexibility, limited featureset which is the reason or...
I think this is mostly a misunderstanding. Maybe there are fixes we have to make specifically for Heroku, but...
@deep-c the server is production ready, it just simply does not do anything besides serve up your ~/dist
directory when in production. At that point, you're better of using a web server meant for that job (Nginx, Apache, et al.) rather than a node server. The deployment strategy should be exactly what @DonHansDampf mentions (though there are other ways of deploying the ~/dist
folder), meaning that unless you're also using the Koa server for an API it's better to serve static files than run an additional node server.
Thanks for the answer @davezuko. I have to say i like this package more and more. Its clean and simple. But the deployment was somehow a let down for a moment. I started again and looked into the code. Deploying to Heroku isnt that hard it seams at first. At all there are two solutions:
~/dist
folder from the .gitignore file. Change the NODE_ENV
for npm run start
to 'production' in the package.json
. First run npm run compile
then push to heroku via git push heroku master
. Simple as that. npm run start
command in the package.json
to: /.../
"start": {
"command": "npm run clean && npm run compile && babel-node bin/server",
"env": {
"NODE_ENV": "production",
"DEBUG": "app:*"
}
},
/.../
Tell Heroku to also push the devDependencies to build the App on the server via heroku config:set NPM_CONFIG_PRODUCTION=false
. Now push to Heroku via git push heroku master
. Now it should build the app on every start and serve the dist folder. (can take some time on every restart).
Maybe we could add this somehow in a clean way to the Deploy Section and add also your description about the server?
@DonHansDampf Those are all great suggestions. I will try to condense them down and add them to the README tonight/tomorrow. An additional solution could just be something like:
// npm run deploy:serve
"command": "npm run deploy && npm start",
"env": {
"NODE_ENV": "production"
}
@davezuko That's also a nice solution. The only problem is: Heroku always runs npm start
to start an app. I looked into the heroku wiki but wasnt able to find a way to change the default command (propably via the package.json
?). But we could define a postinstall
script. (Same as npm run deploy
) Heroku will run this after npm install
. This way npm run start
could be clean as it is. And it would be more clear for new users what happens on the heroku server. (Push to Heroku, Install Modules, Run Postinstall Routine to build the files, run koa to serve the files.) This way the Heroku server will also respond faster since it doesnt build on every restart (for example after sleeping). But we would still have to change the heroku config to push devDependencies.
Is it possible to deploy the app directly onto a gh-pages branch? I'm not sure why would a custom server be required since we only have static files (index.html, app.js, vendor.js, app.css, favicon.ico...).
This would be extremely convenient.
Hey @YannBertrand ! No there is no need for a custom server if you just want to host the static files in the dist folder. You only need one if you use the koa server for other things besides hosting like serving a rest api. Deploying to gh-pages works like every other deploy to the gh-pages. Simply run npm run build
and deploy the files inside the dist
folder.
this is really a "front-end" kit
heroku is a paas—the whole idea is to abstract production hardening and deployment... so, just because the included server runs on their platform does not make it "production ready"
as @davezuko suggested, you should use this kit to generate highly optimized, static distributables and then use a battle-tested, purpose-built server for assets.. run your api as a separate service. if you are managing your own ops/servers, i recommend openresty (nginx) or h2o (http2)... however i prefer the "serverless" approach using s3 behind a cloudfront distribution to serve statics with something like s3-plugin-webpack to automate deployments
Closing in favor of a todo task in our chore to improve the readme: https://github.com/davezuko/react-redux-starter-kit/issues/765
Hi @DonHansDampf !
I tried the second approach that you defined above for Heroku deployment:
`/.../
"start": {
"command": "npm run clean && npm run compile && babel-node bin/server",
"env": {
"NODE_ENV": "production",
"DEBUG": "app:*"
}
},
/.../`
However I get babel-node: not found
error in Heroku logs just after compiling in Heroku finishes. And I already installed the babel-cli packages.
Am I missing something?
Thanks in advance
This Pack needs a better description how a production-ready server can get implented. The Pack itself is great and its fun to work with it. But people will stop using it, when they realise they cant deploy it easily to popular server-structures like heroku.
A Beginner will not notice, that after including devDepencies to Heroku and reading the linked issue #571 that he still doesnt have a running webserver and will get an empty page.
Sadly i also didnt get it running after that. I dont know what i have to do to get an simple production ready server or just "test-deploy" to heroku. Even after changing
/server/main.js
so i also uses the "not stable" sever in production:... if (config.env === 'development' || config.env === 'production') { ...
it doesnt work. Since it cant find the the duck-files:And yes, i know that the Pack cant include a production-ready server. But maybe another branch?