Update README w/ info on dev server

[eriktrom]

Explain the server stack provided by generator-thorax and how to run the client side compilation decoupled from the server(which previously was not possible)

New tasks provided:

grunt noserver
grunt autotest:noserver

Which do the same as their counterparts, grunt and grunt autotest but without booting a server(normally done via grunt-contrib-connect).

Booting a server can then be done with Nodemon(or any tool of choice) in a separate window allowing these two parts of development to be decoupled.

An example server file has been provided within server/server.js and will work for most use cases during development. It is meant only to be an example and is not exhaustive, therefore no persistence layer is included(for example).

Building a node server is an exercise left to the user and generator-thorax tries not to enforce an opinion in this regard.

Note that server/server.js will is also be used by grunt-contrib-connect as middleware when running grunt and grunt autotest, thereby reducing duplication.

Also note that server/server.js is not booted by the Procfile nor is it referenced via npm start(used by nodejitsu). Both of those setups reference ./server.js which is a very light stub server file meant only to provide the bare minimum needed to server the ./dist directory.

To summarize: (aka, essentially rough draft version 2)

server/server.js server public and it's assets and provides can be run alone during rapid development by running grunt with the noserver oriented tasks mentioned above. Furthemore, server/server.js is also used as middleware for grunt-contrib-connect when running grunt default or grunt autotest

./server.js will only server ./dist and is therefore mean to be used when deploying to Heroku(it is referenced in the Procfile) or nodejitsu(referenced in package.json npm start command).

Side Notes:

At some point in the future we'll likely remove ./server.js and simply use server/server.js to server both public and dist, however this idea may or may not be a good idea, please open an issue if you feel strongly either way. The current implementation is more flexible but obviously requires more thought and configuration.

The above is a rough draft, (well 2 versions of it really) -- something more formal needs to be added to the README and/or perhaps the server files should be consolidated.

@mulderp - i know you we're curious about this a while back. Sorry for the delayed response. Curious about whether the above makes any sense or needs better wording.. or what your thoughts are in general here

[mulderp]

Thanks, looks like a nice writeup. I probably would go the nodemon route per default, to have the live reload active.

I wonder if it would make sense to do the Rails approach, similarly as the environments in config.
That would give something like

/config/environments and or /config/servers

development.js production.js  test.js

I guess it would make sense to have separate environments.

Apart from that, what might be nice would be a strategy similar to canned, read default responses as in https://github.com/oreillymedia/backbone-atlas/blob/master/test/canned/builds/index.get.json

[mulderp]

Also, in the default dev server, there should be something like ping route, that you see, where the API endpoints should be added.

[mulderp]

Another trend to consider is that @noBackend approach, e.g. firebaseapp etc. I am still considering a local API more convenient for development, but maybe for production that might be important to switch/mount the app differently.