johnbrett
commented
8 years ago Hi @mmc41, thanks for all the feedback. I'll try answer all your questions:
1) Apologies for this. I thought I mentioned it, blipp just prints a list of all the routes of a server on server start which is very handy for debugging/developing.
2) There isn't a set approach for this type of scenario really. Everyone will offer different opinions, so I'll offer mine :) Lab (the test runner mentioned) isn't specific to hapi, I've used it when developing with other node frameworks, but it has dedicated features useful for testing hapi applications. I find it's the best test runner for developing node applications for it's ease of use, and the number of features it has built in like testing global leaks, code coverage and linting out of the box. It's downside is that it can't be used for UI testing.
Angular is a frontend library with specific features/limitations/idiosyncrasies, and it's needs are usually quite different to a server framework. You can try use a single test runner, like mocha, which is usable on both client and server, but may loose some specific needs, like testing domains in hapi, or something like UI snapshot testing (I haven't verified it can't do this, but last I heard it wasn't a thing). My approach would be to use dedicated tools for each framework, lab for hapi, and last I heard there's protractor and jasmine for angular (but I'm not an angular dev, I use react for frontend dev and am more familiar with their ecosystem).
3) I understand your sentiments here. I would have liked to elaborate more here, but I had limits on page count, and combining explanations and examples would have thrown me way over. I added this sample project to show examples of what I did to get 100% coverage here.
Before working with node, and especially hapi and lab, I would have agreed 100% coverage is crazy. But I've found from a combination of things such as how quick tests run, the quality feedback tools like lab provide, as well as what you mentioned easier integration testing and monkey patching 100% is achievable. All of my hapi plugins have 100% code coverage, and recent projects I've built, even when not using hapi have 100% code coverage. My usual approach is to set up a script like this:
"scripts": {
...
"test": "lab --coverage --parallel",
"test-watch": "nodemon ./node_modules/.bin/lab --parallel",
"test-watch-coverage": "nodemon ./node_modules/.bin/lab --coverage --parallel"
}nodemon runs a command every time a file change is detected, so for every file change my test suite runs. So with this, I use my tests to test the code, instead of manually using REST clients to check endpoints. This takes a little practice to get good at writing tests, but once you do that, I believe you will be far more productive and produce less bugs.
4) There are tools like this: https://github.com/wcandillon/swagger-js-codegen. I would like to use these more, and add them into my workflow so I can build clients for my apis, but I just haven't had the time to do this properly - yet :). If you are trying let me know, happy to collaborate!
5) Generally the approach here would be to have a frontend server which loads your static files for angular, or whatever frontend framework, and this communicates via xhr with your REST server. Something like this might give you guidelines: https://github.com/molekilla/rutha-2016 (but I don't have experience with this particular project). Other boilerplates here: http://hapijs.com/resources#Boilerplates
6) When I began writing this book Typescript was barely a thing :) Shows how fast the JS world moves! I've developed many node projects at this stage and still have never found any need for Typescript, and I think it has slow adoption in the ecosystem too. I find I rarely need to worry about types when developing, but am more concerned with input data validation for which joi has me covered. There has been discussions about Typescript here though: https://github.com/hapijs/discuss/issues/199 if that helps.
Hope all this feedback has been helpful @mmc41, any more questions let me know 👍
I have bought the paperback edition of your book. I have read it and is generally happy with my purchase. Good book. Nice that it is short, to the point and an easy read.
Some feedback (I have very little nodejs experience): 1) In chapter 1 'blipp' is mentioned and used without actually explaining what it does. 2) In chapter 4, it mentions specific test tools without explaining if they are specific to hapi, how they compare to other js tools etc. For instance, I wonder what test tools to use if I use hapi in combination with angularjs. One for hapi and one for angular? 3) In chapter 4, it lacks advice on how to actually get 100%. In other programming universes like Java, 100% would be considered borderline insane from a economic standpoint. Is 100% doable in this context because of easier integration testing, javascript's monkey patching possibilities etc? Also, even with 100% coverage, if you do not have the right asserts the coverage is misleading as a quality indicator... All in all, I think this chapter should offer more practical advice. 4) In chapter 6, I like the swagger mention. I believe the client could get the validation rules from swagger if the joi rules are exposed to swagger. I think I saw some some mention on joi-swagger integration for one of the hapi swagger plugins but I am not sure. Have you looked at this? 5) I miss information on how to integrate a rest backend in hapi with an angularjs 2 gui (possibly versus using an isomorphic approach). 6) I miss information on using typescript with hapi. I also think some of your examples could be slightly more typescript compatible. E.g. using request.params[name] rather then request.params. I want to use typescript with hapi but I am not yet sure what problems I will run into apart from this issue and the require statement that need to be in ES6 format.
P.S: If you do updates I will be happy to review them.