6
votes

I'm having trouble setting up a development workflow that will do both of the following tasks simultaneously:

  1. Recompile static assets (js, css) on file change. Serve these static assets. Notify the browser that the page must reload whenever assets are changed. Use react-hot-loader.
  2. Use express to run a server which serves an API which the static assets will "consume". Have this express server restart any time my server files change.

Is the best practice to have webpack-dev-server serve the static assets, and have a separate web server serve the API on a different port? If so, the API calls in the javascript will need to specify the host and port, and will need to be changed before going to production. It seems all the tutorials online focus on #1, and don't set up an API server. Can anyone point me in the correct direction?

I'm not opposed to using gulp and browserify or SystemJS instead of webpack, but it seems that if I want to use react-hot-loader, I need to use webpack.

2
any boilerplate on github that does it ? - bdavidxyz

2 Answers

3
votes

You can do something like this:

  • Create an express() proxy
  • Create a webpack-dev-server
  • Link the assets with absolute url
  • Start both servers.

Note: Make sure to have different ports to run both the servers.

var proxy = require('proxy-middleware');
var express = require('express');
var url = require('url');

//----------------- Web Proxy--------------------
var app = express();
app.use('/assets', proxy(url.parse('http://localhost:8000/dist/assets')));
app.get('/api/url', function(req, res) {}
app.post('/api/url', function(req, res) {}

// ---------------Webpack-dev-server---------------------
var server = new WebpackDevServer(webpack(config), config.devServer);

// ---------------Run both servers-----------------------
server.listen(config.port, 'localhost', function(err) {});
app.listen(8080);
0
votes

We have been using gulp+webpack for the last year and it has been great. We have an API Gateway which only serves up one static html file(the index.html) and everything else is just REST end points. Then in the index.html we reference a css file or two and a couple scripts that load from our CDN(Cloudfront).

If you run that way in production, your local setup just needs to use the webpack dev server as your "local CDN". You are correct, your javascript will need to know what the api url is since that will change local vs production. We actually have local, dev, stage, and production - once you have it setup to work in 2 environments its not hard to add more(which is good!)

Now our index.html has some template variables that get filled in by the API Gateway when it serves it up. Similar to this:

<script>
  var siteConfig = {
    apiBase: '<%=apiBaseUri%>',
    cdnBase: '<%=cdnBaseUri%>'
  };
</script>
<script src="<%=cdnBaseUri%>/assets/js/bundle.min.js"></script>

Then you just pull in siteConfig when your react app is starting up and prepend those variables to any api/cdn calls. Swap the variables depending on your environment, and bam, you're done!

A slightly simpler approach is instead of filling in those vars when the page is served up you could do it at build time. Thats how we started but as things evolved it turned out easier to manage at run time.

BTW, I am pretty sure you can accomplish all of this using just webpack - gulp probably isn't necessary but it was easier for us at the time to use gulp for running unit tests, linting, etc.