https://github.com/catamphetamine/webpack-react-redux-server-side-render-example
A sample React/Redux/Webpack project with Server-Side Rendering
https://github.com/catamphetamine/webpack-react-redux-server-side-render-example
Last synced: 2 months ago
JSON representation
A sample React/Redux/Webpack project with Server-Side Rendering
- Host: GitHub
- URL: https://github.com/catamphetamine/webpack-react-redux-server-side-render-example
- Owner: catamphetamine
- Created: 2015-12-15T10:45:15.000Z (over 9 years ago)
- Default Branch: master
- Last Pushed: 2023-06-02T17:43:52.000Z (about 2 years ago)
- Last Synced: 2025-03-31T16:17:12.478Z (2 months ago)
- Language: JavaScript
- Homepage:
- Size: 2.69 MB
- Stars: 248
- Watchers: 9
- Forks: 36
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
This sample project illustrates a React/Redux application with optional server-side rendering bundled with Webpack.
Features
* React
* Redux
* Server-Side Rendering in production mode ([optional feature](https://github.com/catamphetamine/webpack-react-redux-server-side-render-example/blob/16dc96b2c14742c007d1e3e740a622a88a18bf2d/rendering-service/main.js#L77-L91))
* Webpack 4
* Development mode: hot reload for React components, hot reload for Redux reducers and actions
* (optional) [Code splitting](https://github.com/catamphetamine/webpack-react-redux-server-side-render-example/pull/40)
Quick Start
===========
* `npm install`
### Development
Note: _The development script currently doesn't seem to work on my Windows machine._ It stalls for a long time and then throws an [error](https://stackoverflow.com/questions/61936085/error-from-chokidar-c-error-ebusy-resource-busy-or-locked-lstat-c-dump):
```
[Error: EBUSY: resource busy or locked, lstat 'c:\DumpStack.log.tmp'] {
errno: -4082,
code: 'EBUSY',
syscall: 'lstat',
path: 'c:\\DumpStack.log.tmp'
}
ERROR: "development:client:build" exited with 1.
ERROR: "development" exited with 1.
```
* `npm run dev`
* wait for it to finish (it will say "Now go to http://127.0.0.1:3000" in the end)
* go to `http://localhost:3000`
* interact with the development version of the web application
* `Ctrl + C`
### Production
* `npm run production`
* wait for Webpack to finish the build (green stats will appear in the terminal, and it will print "Webpage rendering service is listening at port 3001" when the application has started)
* go to `http://localhost:3000`
* interact with the production version of the web application
* check out `./build/bundle-stats.html` and `./build/bundle-stats-2.html` for detailed info on which modules [take up the most space](https://blog.etleap.com/2017/02/02/inspecting-your-webpack-bundle/) in the output bundle
How to see non-minified React errors during npm run production
#####
Replace `--mode production` with `--mode development` in `package.json` in `production:client:build` script.
Summary
=======
This application consists both of the "client side" and the "server side" (for illustration purposes).
The "client side" is the javascript code (`./src/index.js`) which is built by Webpack and run in a web browser, along with the "page rendering service" (`./rendering-service`) which does the same thing but in a Node.js process on the server providing "Server-Side Rendering" capability.
The "server side" consists of the "API" (`./api`) and the "proxy server" (`./proxy-server`).
The "proxy server" approach illustrated in this app is for illustration purposes only. It is considered old-fashioned now as all modern applications are becoming more distributed and decentralized running API in a cloud (e.g. Amazon Lambda) and serving "statics" from a whole another place (e.g. Amazon S3, configured via `output.publicPath` in `webpack.config.js`) in which case the React application queries the API server by an absolute URL (this is called "CORS") and no proxying is needed, therefore the whole "proxy server" is moved out of the equation.
In this example though, for simplicity, "proxy server" is used and it runs on port `3000` and routes all relative URL paths to their destinations:
* "statics" ("static files", "assets") are served (in production mode only) on `/assets` URL path
* `/api` is proxied to the "API server" (running on port `3002`)
* all the other URLs are proxied to the "page rendering service" (which runs on port `3001`).
In development mode there's one more Node.js process running: `webpack serve` is running on port `3000` which serves the "assets" compiled by Webpack (live) via HTTP protocol. In production there's no `webpack serve` and Webpack just outputs those compiled assets to the `./build` folder and the "proxy server" serves those "assets" from there. In a real production environment though this "hand made" sample proxy server would have been dropped in favour of a proper proxy like NginX or HAProxy.