Separate Webpack Dev server from API server (fixes #1348)

[andrewn]

This extracts the webpack dev server into it's own process, run with npm run start:client. This allows contributors to just run the web app.

There are a couple of others parts to this:

• staging server URL needs to be configured
• CORS needs to be configured for staging (PR Always allow localhost CORS requests #1398)

I have verified that this pull request:

• has no linting errors (npm run lint)
• is from a uniquely-named feature branch and has been rebased on top of the latest master. (If I was asked to make more changes, I have made sure to rebase onto master then too)
• is descriptively named and links to an issue number, i.e. Fixes #123

[hydrosquall]

Hi @catarak, finally having some time to look at this project again due to the holiday - what do you think about this change?

Once this is in place, I could continue with #1257 . This would open the door to us being able to easily have per-branch preview deploys, which should hopefully make it easier for maintainers to review the functionality of PRs without needing to copy the changes locally every time.

[catarak]

Thanks for bumping this! Right now, I have the staging server set up with basic auth, which works great with a relatively small number of people testing changes on develop but is not super compatible with running the front-end locally and using the staging server API. But I guess this change would allow the two to run separately, so that the front-end could be password protected, and the back-end could be CORS protected.

So I think what needs to happen is that this PR needs to be updated so that server-webpack-only.js can be password protected with basic auth, and basic auth needs to be removed from server.js. Maybe also the names of these files should be changed—do you know what the conventions are here? Like server.js and app.js? api-server.js and app-server.js?

[andrewn]

So I think what needs to happen is that this PR needs to be updated so that server-webpack-only.js can be password protected with basic auth, and basic auth needs to be removed from server.js. Maybe also the names of these files should be changed—do you know what the conventions are here? Like server.js and app.js? api-server.js and app-server.js?

server-webpack-only.js would only ever be used when developing the Web Editor without running the API server locally. It runs the Webpack Dev Server, and wouldn't be used in production. When running in production, the server and app would continue to run as it does now, using './server/server'. I don't think app.js makes sense as a name, since it's only used for development... perhaps server/app-dev.js?

I'm not sure that we'd need server-webpack-only.js to have basic auth enabled since it won't be run on the staging server.

I think what we want is:

1. to have basic auth in front of the staging web app UI - so only those with access can log in to see new features;
2. the staging API endpoint should be accessible by via CORS, either for the the staging web app or for local developer.

Both of these changes need to be made in ./server/server.

[catarak]

server-webpack-only.js would only ever be used when developing the Web Editor without running the API server locally. It runs the Webpack Dev Server, and wouldn't be used in production.

oh duh of course!

When running in production, the server and app would continue to run as it does now, using './server/server'. I don't think app.js makes sense as a name, since it's only used for development... perhaps server/app-dev.js?

app-dev.js makes sense to me!

1. to have basic auth in front of the staging web app UI - so only those with access can log in to see new features;
2. the staging API endpoint should be accessible by via CORS, either for the the staging web app or for local developer.

Both of these changes need to be made in ./server/server.

This approach makes sense to me!

I've also been in contact with a new tool called Release which will deploy pull request builds (and do other stuff too), but I still think it's worth it to get this in so that folks can do development and only run the front-end application.

[raclim]

Thank you so much for taking the time to contribute to this issue! Since some time has passed I'm going to close this for now, but please feel free to reopen this or work on this again, thanks!