Create a character voting app using React, Node.js, MongoDB and Socket.io(sahatyalkabov.com) |
Create a character voting app using React, Node.js, MongoDB and Socket.io(sahatyalkabov.com) |
I spend a reasonable amount of time developing and maintaining a reasonable sized js based front end to an application, which uses React heavily (40k lines). Looking at this, I can't help but think that isomorphic JS apps make life far more miserable than separate back and front end applications.
To get a decent server running on a linux distro - Nginx, Mariadb, PHP/Python/etc. An apt-get and your updates are handled nicely for you. Dependency management via Gulp is better than nothing, but jeez it still sucks so bad.
Building a nice, RESTful API on a more sensible back end infrastructure is far less complex, has a vastly smaller toolchain (just a small library for routing and db connection handling would do), plus you get the joys of things like Schemas and ACID from a proper RDBMS (because seriously, Mongo? We really still think that's a good idea?).
That's before we even get on to Step 4. ES6 Crash Course. Or, here's things to know about a language that you can't use on the client browser, because it's not actually a thing there, so you can't use all that you'll learn here when you write JS.
It's insane that people think you need to do all this just to get a live updating counter. What's wrong with a tidy back end with ZeroMQ for your pubsub style socket handling to allow real-time event based change publication, and a separate front end?
It feels like you have to do a hell of a lot of work to get JS + your favourite V8-based server to do anything, and none of it easily.
It's basically a single webpack config (that's heavily commented, btw!) and a set of npm run-scripts. You don't need gulp to build an application! And I would not call bower a sane way to include frontend dependencies... Not by a long shot.
1. seamless ES6 transpilation at runtime (no build steps needed)
2. load libraries in any package format as ES6 modules (Globals, CommonJS, AMD, ES6) from any source (local repo, Github, NPM)
3. no need for injection (you can import css and html programmatically using extensions)
It does introduce some friction of its own due to it being a relatively new project, but not enough to offset all the benefits it brings, in my experience.
Dismissing this guy's tutorial because he didn't clone Facebook is kind of short sided. Everything is about trade offs. You don't need to make your React app isomorphic if you don't mind a slower initial load and lack of SEO. You don't need to use Mongo, you can pass data from your RDBMS directly to your components as props when you render server side or have them call your REST API using an isomorphic request library. You don't need to use ES6 if you use something like webpack and babel.
But if you have heavy competition and need a snappier first load experience, it is an option you have.
Server is Nginx. Evaluating HHVM for migration is an ongoing concern, but there's some edge cases we run in to where it does wonky things. That said, within the next ~12 months, I expect we'll be on it.
MariaDB, with query results cached on Memcache. The data we deal with is massively relational, with some very large tables and result outputs, so there's no way around using a tidy RDBMS for us, and consistency is a big thing.
PHP, with a few tiny, high speed libraries for DB connection management and routing. As far as possible everything uses PHP functions that map directly on to underlying language equiv, and we make a lot of use of streaming and generators, which makes memory overhead nicely manageable. When HHVM becomes a thing for us, we'll then start pulling some of this over to Hack.
That's all set up as a bunch of RESTful APIs, which are reasonably HATEOAS in their outputs. Output format is either JSON or HTML, depending on request params.
Front end is a bunch of React bits. We're slowly converting into React, so initially we used HistoryJS to manage URL history, along with React to render stuff. Qwest for XHR handling, and a few little libraries and helper functions (of note: moment.js and numeral.js).
Everything then gets executed on the client. Current roadmap is to build something akin to React router for managing loading of assets and better history management, and to pull the entire front end into a single application. At the moment, it's better thought of as a bunch of distinct SPAs, operating over a common middleware.
Architecturally, the back end services are written MVA, with data going through our own DAL, with RBAC sitting in front of everything. Caching is handled in the DAL, so everything acts as a black box - models don't know where the data came from, adapters don't know where the model got it's data etc...
The front end is written loosely around a Flux style architecture. Data is held in a single area, as are all methods that interface with state. Those parts sit at the top, and pass data as props down to UI components, written to be dumb as to where there data comes from.
IO is mostly via single HTTP requests, but with the option to hook onto ZMQ for real time interaction.
Hope that helps! I'm currently writing some lower level thoughts on React on our blog (https://builtvisible.com/blog/) with some more advanced stuff coming shortly.
Apologies for the various TLAs. If you need anything explaining further, shout.
It also absolutely blows my mind. This just feels wrong. 17 separate packages, some providing really basic stuff like serving favicons and parsing POST requests that must be a part of bigger framework. Each package is of different quality, testing strategy, and depends on a different developer who's completely free to abandon his project tomorrow or introduce some backwards-incompatible change. This trend as a whole looks unreliable, like a wobbly house of cards near a working fan.
Welcome to OSS! Really though, there's things like forking, community involvement and SemVer.
The project configuration reflects the developer's decision not to use webserver like nginx, otherwise things like serve-favicon and express.static would be unnecessary.
I setup a project scaffold [0] with a configuration that supports development, production, and testing environments. It has a heavily commented webpack config.
No tests? No asset cache busting by updating name references? Come on, those are basic requirements for a web project.
On top of that, webpack lets your dependencies be resolved as part of your code, instead of relying on certain files being in certain folders: e.g. your css and images.
Even the todo-mvcs are all ~500 to 1000+ lines.
I've removed node_modules and bower_components from the items in: https://github.com/tastejs/todomvc/examples
I've also deleted "polymer" and "emberjs_require" since they didn't have any files in them and messes up the `wc -l`
$ for x in *; do echo $x; wc -l `find $x/ -name '*js*' -type f | egrep -v 'test|lib|public|vendor|.bundle.js|.cache.js'`; echo; done
Obviously one can improve the filtering to get more accurate results but you get the point. To make a TODO mvc you need at least 5+ different files and totalling a lot of lines. The fact that jQuery solution (which is very nice code, not the typical spaghetti) beats the majority of them in line count is pretty ironic.
I actually think that a simple Webpack configuration for a React project is pretty easy to understand (thanks to Babel). Here is one that I use in one of my projects [1]. Adding Less support is like one additional entry.
[1]: https://github.com/renke/perpetually/blob/master/webpack.con...
I strongly believe you can build web applications without having to pull in Gulp or Grunt. And to back up my claim I setup a project [0] that shows how to do it using webpack + npm run-scripts.
I'd argue it solves a large set of problems while maintaining a reasonable level of complexity.
I ignored Grunt for years, always implementing my own hackneyed systems in Python, until I eventually discovered this tutorial[1], which at least got me a good introductory "this is how you use this thing that everybody else already knows how to use, dummy" lesson.
Yeah they did kind of just sneak up about a year ago it seems. I remember getting into the field two years ago I didn't hear about them. I suspect the tipping point was the full migration to front-end frameworks instead of just plain JS/jQuery.
This is a react render function mentioned in the tutorial (gist with all code here[0]):
render() {
let delta = this.props.delta ? (
<strong className={this.props.delta > 0 ? 'text-success' : 'text-danger'}>
{this.props.delta}
</strong>
) : null;
return (
<div className='card'>
{delta}
{this.props.title}
</div>
);
}
<div class='card'>
<%= content_tag_for(:strong, :class => @delta > 0 ? 'text-success' : 'text-danger' ) do %>
<%= @this_props_title %>
<% end %>
</div>
[0] https://gist.github.com/alexggordon/820020aab934bf192b81
> But do we really need a separate template for this? Why not just render everything inside the App component? Yes, you could do it, as long as you are okay with invalid HTML markup and not being able to include inline script tags like Google Analytics directly in the App component. But having said that, invalid markup is probably not relevant to SEO anymore and there are workarounds to include inline script tags in React components. So it's up to you, but for the purposes of this tutorial we will be using a Swig template.
- prepend '<!DOCTYPE html>' to the resulting HTML
- attribute "prefix" in head tag "<title>" wasn't outputted, so until it's fixed in the library, I just use a data attribute "data-replace-prefix" and removed the extra "data-replace-" from the resulting HTML
-------
Also, he could include inline scripts (like Google Analytics) this way:
return <script dangerouslySetInnerHTML={{__html: "THE_JS_CODE"}}></script>;What is your experience in regard to running tests with Webpack?
* Can you test individual modules that use arbitrary loaders specified in your Webpack config?
* Can you run tests from the command line?
* Can you write your tests in ES6/7 (or anything else supported by Webpack's loaders)?
I was looking into combining jest with Webpack but every solution so far would only compile your module directly with Babel and therefore skipping the power of Webpack.
If you want to be able to do everything, you'll have to configure more stuff. Honestly, I don't think it's worth the extra effort to try and configure things to work with every possible workflow. Just setup what you need, and then add stuff in as you find yourself wanting / needing it.
My advice is to avoid jest. It's too slow and clunky. If you want to stub modules, there's rewire-webpack. If you're using babel and ES6 modules you'll probably want to check out babel-plugin-rewire. I think there's a few other alternatives, but I haven't had the need for any of these so far.
On to your questions...
> Can you test individual modules that use arbitrary loaders specified in your Webpack config?
Yes. The solution I have is to maintain a single webpack config maker function that has a bunch of conditionals inside, and then I just use that function from all my configs. When you set options.TEST to true, it'll set the entry point to an empty object.
That means that my tests will be configured as close as possible to my production and development. The same loader config will be used for all the environments.
> Can you run tests from the command line?
Sure. In the web-app repo, it uses karma with phantomjs.
If you want to test your code using node... It's a bit more annoying, but also doable. I've previously set it up like this: create a test.js [0] file, set it as the entry-point in the webpack config, and use webpack context to include all the tests you wanna run, and finally point mocha to the output file. If you wanna use it in "live" mode, you can run webpack and mocha both with the watch flag.
If you just wanna run a single test... You can specify a single test as your entry-point, and then point mocha to it. Again, if you want "live" mode, you can set the watch flag on both mocha and webpack.
> Can you write your tests in ES6/7 (or anything else supported by Webpack's loaders)?
Yes. They use the same loaders as the rest of your codebase.
[0] https://www.dropbox.com/s/35ebqijrp9nqyj3/Screenshot%202015-...
<div class='card'>
<% if this_props_delta? %>
<%= content_tag_for(:strong, :class => @delta > 0 ? 'text-success' : 'text-danger' ) do %>
<%= @this_props_delta %>
<% end %>
<% end %>
<%= @this_props_title %>
</div>
One could just as easily argue:
<div className='card'>
{() => { this.props.delta ? (
<strong className={this.props.delta > 0 ? 'text-success' : 'text-danger'}>
{this.props.delta}
</strong>
) : null }() }
{this.props.title}
</div>
render() {
return (
<div className='card'>
{this.props.delta > 0 &&
<strong className={this.props.delta > 0 ? 'text-success' : 'text-danger'}>
{this.props.delta}
</strong>
}
{this.props.title}
</div>
);
} <div class="card">
title
</div>
<div class="card">
<strong class="text-success"> delta </strong>
title
</div>
<div class="card">
<strong class="text-success">
title
</strong>
</div>Now, to be fair to Grunt, my workflow is usually Python or Go on the backend, and I just wanted something to manage my front-end assets, so it was never a necessity for me, but knowing there's something that does what I want it to do, while being unable to make it do the thing that it does is quite frustrating.