Assignment9 and Beyond

[zoe-1]

Where are we going next? Most of the goals discussed at: #132 have been achieved.

Below is a list of subjects discussed earlier that have not yet been covered or were lightly
covered. @FennNaten made most of the below recommendations in the discussion at: #132.
Read the below and share your thoughts about the direction of the university :-)

• Caching handling, both client-side with hapi abilities and server-side with catbox.
  Caching correctly is critical to have reactive websites.
• We have done nothing with caching yet.
• Role-based authorization. There may be plugins to do that already, or it can be handled by using several auth strategies,
  but it would be cool for everyone to try an implementation, saying e.g. that roles that can access a route should be provided as route configuration,
  and role-check performed at post-authentication. This would drive us into using request lifecycle hooks.
  • This has been explored some with hapi-auth-cookie and scopes but we could go deeper.
• Maybe having some data exposed using CORS and/or jsonp (let's say our awesome website exposes a little public module
  for people wanting to display our latest news on their own site) Some form of content negociation.
  Let's say e.g. that our nice 'latest news' endpoint can serve the data as xml, json or plain text depending on request headers.
  Routes documentation with lout.
• Configuration switch tied to environment maybe (e.g. dev/test).
• Some client-side js loading data from our API via ajax requests ?
  Provide error pages to hook on some http statuses (unauthorized, 404, server errors).
  Would be another opportunity to hook on the request/response lifecycle.
  • Already covered this but we could go deeper.
• @simon-p-r on gitter mentioned configuring tls options for ciphers and honorCipherOrder which control the protocol level used.
  I have not researched this but it's here for discussion.
• Making proper use of a database.
  
  Over the past several months, many expressed the desire to include a database (See Potential [Assignment 5] Glue and HTML views #132).
  At this point in the project, it would be reasonable to include a DB. Since hapijs is part of the
  JavaScript and node.js universe, it would be appropriate to use a JSON document database like couchDB or Mongo. Or, perhaps the community wants to keep the university focused on JavaScript and hapijs. What are your thoughts? Personally, I think database support would make the university much more interesting and attractive to people who are considering changing technologies and begin using hapijs.

I have been preparing to use couchdb in a hapijs application by writing logic with 100% test coverage here: sofajs This project is not complete but it illustrates a direction we could head with couchdb (nano and 100% hapijs/lab test coverage)

Other Ideas:

• image/file uploading
  Most developers would benefit from some file uploading code. Coming from Rails I still appreciate plugins like: paperclip. I have not seen anything like this in the node.js world. Perhaps it exists, but I have not found it yet.
• Consider contributing an assignment?
  If you see a subject in the above list you have experience with, consider sharing your knowledge by writing an assignment :-) You will learn more by teaching a subject than studying it.

[Couto]

I know I've not been doing the exercises or delivering assignments, but I've been following the project.

Personally, I would really be interested in seeing more about cache handling and role-base authorization, and I would like to see some examples of image/file uploading, but I feel that could be done on a a future assignment where you allow some privileged users to upload photos and store information about them on a database (or something similar...)

Anyway these are just my votes!
Keep up with the good work ;)

[zoe-1]

@Couto good to have your input :-)
In respect to role-base authorization, what would you like to see? Currently, the project uses scopes
and hapi-auth-cookie to check if a user's role is authorized to access specific routes or not. What other RBAC features would you like to add?

[Couto]

I have to admit that I don't dwell too much with backend code, so take my case with a grain of salt, or dismiss it at all if it doesn't make sense.

My problem with RBAC is when several roles can use the same endpoint to perform an action but with different privileges. e.g.:

Having regular users, moderators and administrators. All roles can upload an avatar to their profiles by performing a POST request to /upload, however, regular users can only upload 128x128 images, moderators are allowed a bigger limit like 256x256 and administrators can upload anything they want.

What's the best way to manage all this? I guess that in the specific above example we'll always have to get the image first, check its dimensions and then perform the appropriated action, and I have to admit that I'm missing a better use case, something where you could check their privilege before performing any kind of action.

Mostly likely I'm just missing something simple... :)

[devinivy]

On the topic of role-based authorization, it's worth checking out the mrhorse plugin, which allows you to add lifecycle hooks on route configurations (called "policies"). There's also rumor hapi9 may have proper per-route lifecycle hooks: hapijs/hapi#2566.

[Couto]

@devinivy Thanks for the suggestion! I can see mrhorse being quite useful 👍

[mikejerome]

I'm also interested in role-based authorization

[james-gardner]

Personally I would love to see a demonstrated approach/assignment that details database integration. I've learned heaps from the assignments so far - can't wait for the next - thanks!

[devinivy]

Would there be any interest in a version of this tutorial extended into an assignment? It would be about integrating hapi with waterline ORM to create an API.

[james-gardner]

@devinivy Looks great. From a newbie perspective I'd be keen to understand the low level aspects first (i.e. what these plugins literally save me doing) before moving on to an ORM and so on. The assignment with 'glue' was really useful in that sense because I could see how much effort it was saving me and what the objectives were.

[devinivy]

Thanks for the feedback. Yeah, this is a few steps further removed from hapi than glue, and it's a bit more complicated to relate the value of these plugins. If there's more interest, it would also be nice to reach out to @moklick who wrote that tutorial.

In the interest of transparency, I'm the lead maintainer of those two plugins and a collaborator with waterline ORM. That both makes me a good candidate to help write the assignment, and also necessarily biased :P. But if there's interest in working with databases in hapi, I do believe it would be a useful route to explore.

[zoe-1]

@devinivy and @james-gardner @mikejerome and @Couto

It is really good to have everyones input. From the above comments it seems that most people are interested in role-based access controls and integrating a database. I suggest we pursue both of these objectives in the next couple assignments by: one, integrating a database into the project. two, providing features that utilize RBAC (Role based access controls).

In respect to a database, over the past several weeks, I have been researching intergrating couchdb into our project. There are several things I really like about couchdb:

• Multi-Version Concurrency Control (MVCC) and the revision tracking system to manage concurrent access to the database. Every time you update a document couchdb makes a new revision id of the document and tracks all the old revisions. It is like every document having triggers already written to track changes. However, this revision system is also used to provide the next important feature I like about couchdb.
• Eventual consistency and replication. MVCC enables couchdb to provide eventual consistency and replication. Many applications can all have a local version of couchdb running and then eventually be consistent. See couchdb docs for details.
  
  This gives couchdb the ability to be:
  
  a distributed system that operates robustly over a wide network.
  
  why couchdb
  
  eventual consitency
• npm registry utilizes couchdb which provides the ability
  to create local npm registries. This illustrates couchdb's distributed abilities.
• the above shows that couchdb is a huge part of the node.js ecosystem. npm depends on it.
  The embrace of couchdb by npmjs makes it more appealing.
• nosql - the project should move away from SQL databases to a JSON document based db.
• view models - couchdb uses "designs" that implement view models.
  This logic has some parallels with ORMs which should be helpful for people with ORM experience.
• the documentation for couchdb is great. You install it on your local machine and read
  it without internet access.
• couchdb provides futon to work on your database through a local browser which
  is a nice convenience.

How to approach couchdb.

I suggest using couchdb with nano because nano
is minimalistic and will force us to really get to know couchdb. A high level tool like cradle would
create too much separation between us and couchdb.
Warning:

• if we approach couchdb this way it will make us write more code and possibly distract us
  from just focusing on hapijs. The risk is worth taking because couchdb is very powerful and anyone considering using hapijs is also going to consider using a database with the framework. So, nice sample code illustrating hapijs being used with a database would be valuable.
• the learning curve for couchdb is steep and writing unit tests providing 100% test coverage for all db query logic can be wearisome. But, the rewards pay off big in the long run.

note about redis

Eventually, redis should be included in this project but to approach two databases
at the same time would be too much. First, include couchdb and get to know it really
well inside of the hapijs environment. Later, redis would be added.

Please give feedback.
Cheers!

[rutaihwa]

I'm still very interested, when are we coming off hibernation mode.

[zoe-1]

@rutaihwa Good to hear from you.
Here are some thoughts about future direction.

• The hapijs project has moved on to version 11 so we need to rework the project to reflect that.
• Currently, desire to make the project become a spa (single page application) or several small spa apps using react and backbone for the router. It would be valuable
  to illustrate a client using react in a hapijs project.
• build an api which utilizes couchdb to manage data and support serving various clients
  (android ios etc). Want to support any device that utilizes web views. Recently, spent a lot of time building sofajs and using it in a project. It is a tool useful to build and organize all code that interfaces with couchdb. Next week plan to publish all CRUD (create, read, update, delete) code for managing user data in a project. This should
  be useful in the university project. Plus, plan to update the sofajs project as well.

Work responsibilities have been big so have not tackled writing another assignment. However, on the positive side of things, the current project covers the core elements of setting up the hapijs framework and people seem to be making good use of it.

Next week plan to share more thoughts.
If you are interested in helping move the project forward let me know.
It would be enjoyable to build out assignments with someone else versus doing it alone.

Or, if someone is motivated and wants to contribute an assignment, please open up an issue and make a proposal. With the combination of the holiday coming the end of this month and work being busy, I will not be able to make any assignments until next year. But, I do plan to publish all the couchdb user crud data as mentioned above.

Cheers!

[rutaihwa]

Thanks @zoe-1 this project has been very good and helpful (speaking for my self at least).
The proposals that you are making are interesting. I will be glad to help with little that I could.

I am having my semester final exams this coming week and holiday is coming along with some travellings.

I have been a lot more fixated on working on some sort of beautiful api design but I have not yet started playing with couchDB, but I would like to learn and work it out. I could also help with updating to the current hapi version. All in all, would like to contribute.

[zoe-1]

@rutaihwa I am glad you want to contribute to the project.

I just put up a bunch of couchdb request logic at https://github.com/sofajs/sample .
Almost done writing all the user CRUD logic. Currently, has 100% test coverage for
create and delete logic. And much of the update logic is written but needs coverage.
Take a look at the above and let me know what you think.

[zoe-1]

sample user couchdb queries completed.
To see the work do the following:

• git clone https://github.com/sofajs/sample or go to sample.
• cd sample
• npm install
• install couchdb
  • couchdb.apache.org
  • configure a couchdb admin user
• configure sample/lib/sofafest.js to your couchdb admin credentials.
  • db: 'your-db-name'
  • user: 'your-couchdb-username'
  • pw: 'your-pw'
• npm run load
  • run above command twice. once to create db. next, loads fixtures.
  • after db is created only run once.
• npm test
  • currently 100% test coverage.
• read documentation on all couchdb request logic.
  • npm run docos starts documentation server.
  • visit localhost:9000 and read the docs.

[rutaihwa]

Thanks @zoe-1 will play with sofajs.

[zoe-1]

Your welcome @rutaihwa.
I will look more at your project we have been corresponding about too.