Closed jaredpalmer closed 7 years ago
cc @ctrlplusb @gajus @koistya
There's also a third option, though it cannot be considered an honest "with Webpack" solution.
https://github.com/halt-hammerzeit/webpack-isomorphic-tools + nodemon
These webpack-isomorphic-tools
implement certain parts of webpack
functionality (loaders, require aliases) without actually building through webpack
on the server-side, all the magic happens via magic require
hacking. This approach adds certain benefits, such as you don't need a build step for the server. But it's not entirely webpack-compatible.
And there is the fourth option of the same author which I haven't used myself: https://github.com/halt-hammerzeit/universal-webpack + webpack target: "node"
+ nodemon
@sompylasar yup. also worth exploring solutions with those.
Related, this is about how we did our universal apps ~6 months ago:
https://github.com/ericclemmons/terse-webpack/tree/master/example
Notice how it's a single process with webpack-{dev,hot}-middleware
doing the heavy lifting.
I simply include all the loaders for client on the server side as well and import the client code directly. Inside the server I run webpack for the client bundle. So I have webpack -> universal server with HMR -> webpack -> client bundle with HMR.
I encountered lots of bugs with Babel though, especially if I include things in the Babel config. I should bundle my webpack config first and then run it.
I also wish hot reloading on the server could all be done in memory and not using polling.
Hey here's an idea: use https://webpack.github.io/docs/node.js-api.html#compile-to-memory and then read the entry into memory, prefix it with something that patches require
to use the memoryfs result and eval
it.
For HMR, go deep into Webpack code and implement a mode that uses a global EventEmitter for HMR notification?
Maybe all this needs to be implemented in webpack proper, though. Thoughts?
BTW, is there any good reason to use Webpack in data API / backend projects? Isn't it supposed to be used in front-end projects only? See Node.js API Starter Kit (no Webpack)
E.g. the code is transpiled directly with Babel, no need to minimize the code for the server as it won't have performance benefits. Loaders - it's front-end related concept, using them on backend makes things more complex than they should be I believe, HMR on the server is easy without Webpack, just a few lines of code to cear the cache, require Express module(s) again and run app.listen(..). Demo:
On Sat, Jan 14, 2017 at 3:04 PM Konstantin Tarkus notifications@github.com wrote:
BTW, is there any good reason to use Webpack in data API / backend projects? Isn't it supposed to be used in front-end projects only? Ref Node.js API Starter Kit https://github.com/kriasoft/nodejs-api-starter (no Webpack)
With webpack, you can transpile, and you can optimize => faster production server loading.
You can also use loaders that do special things and use HMR to develop backend endpoints faster (see https://github.com/ericclemmons/start-server-webpack-plugin/) => better development experience.
Just a quick clarification, does backpack support react by default or not?
Technically yes, it is possible. However, I don't think you'd consider it a great DX. All defaults and scripts are meant for Node.js-only and not for the browser right now.
Will publish a fork though that implements one of the above solutions either tonight or tomorrow hopefully.
Will publish a fork though that implements one of the above solutions either tonight or tomorrow hopefully.
Is there a fork or a sample that has the proposed solution for universal apps?
I've been working on the #39 HMR example, but also forking off to see what changes would be necessary for a great DX that worked with:
webpack-{dev,hot}-middleware
create-react-app
next.js
(In an effort to no longer maintain @terse/webpack
:D)
I have a universal react hmr example in progress here. Would need to make major changes to backpack to integrate, but that's okay.
Currently Backpack is focused on providing the best development experience for Node.js server-side applications and libraries.
This was a deliberate decision.
The idea is that people should use tools like Create React App or Next.js for their frontend and then use Backpack to build out API's etc. My goal was to create a complimentary tool.
However, it appears that the community wants a some sort of drop-in solution like CRA's react-scripts but for isomorphic / universal apps. I'm not sure why it isn't more popular, but this is what the New York Times' kyt project aims to do. Personally, I don't care for the aesthetics of kyt (e.g. the emoji's in the console) and for some of the conventions (like extract text/css and the eslint-config airbnb), but those are just my opinions. Regardless, Backpack could technically accommodate universal apps with a few small, yet non-trivial modifications.
In my research, I've come up with two approaches to Universal Apps with Hot Module Replacement and server reloading worth considering:
(Note: these have been extracted from other React server-side rendered projects of mine. However, they are not yet drop-in replacements to
backpack dev
. They do not currently handle custom webpack modifications like Backpack's currently does. These are just POC's).1. Chokidar, Nodemon, Webpack-Hot-Middleware
This serves up client-side assets on another port like
localhost:3001
. It would be up to the user to properly reference where the assets are served from in their apps. This isn't necessarily a bad thing though, as these frontend assets should ideally be served from a CDN in production anyways. We could handle this by providing a Webpack flag to the server for use in the application's HTML template such asBACKPACK_ASSETS_URL
.2. BrowserSync, Proxy-Middleware, Webpack-Hot-Middleware
The following is heavily inspired by Ueno's React Starter project.. It uses a http-proxy and browser-sync to work out the ports. My only criticism of this technique is that browser-sync and Docker do not play nicely with each other at all (last time i checked). That is either irrelevant or a dealbreaker for people.
Anyways, those are some ideas. I'd love to get the discussion going. I've been thinking about this since reading @jlongster 's Backend Apps with Webpack