source maps are in production build

[jakubwolny]

I would remove them because main-[hash].js.map is around 4MB. And because of many other obvious reasons.

[erikras]

They are intentionally left in this project because it is just a starter project, and it is so far from an actual deployable production environment.

Obviously, on a real production system, they would be disabled.

Perhaps some documentation to that effect might help.

[nicolabortignon]

Actually I noticed that as well this morning. @hamczu would be great if you can share how you would see the css compiler pipeline for a production enviroment

[mclouvem]

@erikras Would you mind share some thoughts about what should be done before a project based on this starter kit be deployed in production server?

Some help in this way would be great. This running my first project using redux+react...

[erikras]

The source maps is about it. And really, almost no one is going to see your production source maps because browsers don't download them by default. I've certainly never gone to a competitor's website with source maps turned on to glean insights or steal code, but as a general practice, they should be disabled.

Obviously you'd need an actual auth mechanism. I don't really have a list of todos.

[mclouvem]

I wasn't thinking about a todo list. It would be really nice if users share some tips and some pieces of advice regarding production deployment.

Anyway...thanks for your excellent work on this project!

[rabet]

@mclouvem +1

[krukid]

@mclouvem here are some problems that need to be addressed for a production deployment:

1. set up reverse proxy (nginx) that will handle https, compression, serve static assets and remove express.js middlewares (per express.js performance recommendations)
2. set security headers (frame-options, xss, nosniff, hsts, secure cookies)
3. remove source maps from public access (I believe source mapping should happen on the server side)
4. set strict CORS policies and implement CSRF/BREACH protection
5. use a real logger, e.g. Winston and send logs to file, stdout, Graylog, ... (log window.onerror events to server)
6. instrument the framework with metrics collection for both client and server side (e.g. GA/Google measurement protocol)
7. use all available cores for the app server (node cluster)
8. ensure app servers are restarted on crashes (process manager)
9. make sure zero-downtime updates/restarts (maintain N previous code bundles => remove clean webpack plugin, shutdown old apps gracefully/ restart incrementally)

I'm still working on bringing my app based on this starter kit into production, so this probably isn't the full list :)

[oyeanuj]

@krukid Could you post an update/guide on your recommendations when you go thru all these steps that you have listed? I am going to hit that point soon and it'd be great to learn from your experience with productionizing this starter kit.

[jaraquistain]

@krukid That would be very useful to me as well!

[Richacinas]

And to me as well. Thanks a lot