You start with a blank user with id=1.

Running (production)

npm start

Running dev

npm run start:dev

Note this may reload express which will rest the user record to blank.

Running tests

npm test

npm run test:watch

• I'm assuming node 6.

• I opted for a "User model" approach for the store eg User.find* User#save etc. The other option might have been to go with a "collection" model like the mongodb driver eg db.users.find etc.

• I didn't pick or build in a store (eg nedb, lowdb, leveldb, mongodb, mongoose); I'm assuming the exercise is more interested in how the store is decoupled from the application. I could have perhaps used nedb and had it use a memory store for test and development environments, and a file for production. But it just seemed easier not to pick one given the openness of the requirements.

• I initially started making the model promise-based but switched to callbacks. However User.findUserById is still promise-based. I probably wouldn't mix the two normally.

• Instead of a real store, I have a FakeUser class that acts as the User model with a "just good enough" memory store. This class represents the expected interface this application expects.

• The FakeUser User model is not accessed directly; the code gets it by calling getUserDao function. This decouples the User model implementation and underlying connection mechanics from this application.

• I wasn't sure about the use of sessions from the instructions. I didn't implement any session-based or cookie-based logic in the code. The code has some middleware which ensures that req.user exists (like passport), which can then be used with the hCard components.

• main.js is served up from dist/ by express; it would be pretty easy to put nginx reverse proxy in front and have it serve up assets in dist/ and public/

• I'm assuming tests are part of the assessment.

  • I used mocha/chai/sinon for units tests.
  • Supertest for integration tests not involving a js-enabled client.
  • To test the js-enabled case I used zombie, but found it was slow to download some assets (probably the react cdn), so...

• Probably best to run unit and integration tests without reliance on external network - so I put react client libs in dist/. The version is slightly different to the original version used for the server - we'd pin this in package.json probably.

• The other option might be to stick with acceptance-style selenium tests eg mocha + wd or cucumber + wd for testing full browser functionality even for integration tests. However this would make testing things like http status codes harder.

• Not sure if we can put in a csrf token here. For the non-js, it would presumably be a hidden form field. Didn't attempt to put this in for this exercise.

• Not sure if the avatar code submits. The input field looks to have no name attribute. The task specified application/x-www-form-urlencoded for both /submit and /update which would probably be inefficient for an image and multer only does multipart. So, after playing with multer, I left this one. (there is busboy apparently)