Brivo Labs - SAM API Event Invite and Access Reservation Improvement and Unit Testing

Project Overview

BrivoLabs has a beta version of a node.js/coffeescript application that is called Social Access Management (SAM) API. It uses postgres database, runs on heroku, consists of both a web and a worker process, and uses a redis-based message queue to communicate between them.

Competition Task Overview

The goal of this challenge is to write unit tests and improve code performance of event invites and access reservation controllers.

API in scope

• accessReservation controller and it's corresponding helpers, model and routes.
• eventInvites controller, and it's corresponding helpers, model and routes.

Performance Improvements

The endpoints of controllers in scope are among the top slowest endpoints as reported by new relic transaction reports (see image below), we need to do the following to help us addressing the performance issues :

• Implement pagination :
  • pagination should be generic to be reused by other controllers in future.
  • we expect to have two new optional input parameters to endpoints that implement pagination : limit and offset.
  • The response will remain as it is, we will include two new headers for pagination information :
    • Link header : the best example we can follow is github pagination for this, we include the 4 rel values (first, prev, next, and last links)
    • X-Total-Count header : this should include the total count of entities for the search query without pagination parameters
      • If setting this header will affect performance (responsiveness) then don't include it.
  • it should be enforced, so by default, there should be default limit of X items if limit was not passed. probably making X configurable is good idea.
• As shown in screenshots, also POST endpoints have slow response time and we cannot easily find out the reason without digging into the code, we need to do the following :
  • For methods in scope, you need to dig into it and try to improve the code, the new revamped code should be place in a new method
    • The new method will be accessed via same endpoints but with different versioning header value. Use Restify route versioning to address this requirement.
  • Setup and run benchmark tests : you can research and find best nodejs module that can be integrated with mocha module.
    • The benchmarked tests should run against both versions (old and revamped one)
    • The tests should produce reports that show the performance measures
    • Our target is < 100 ms response time - try your best :)
  • You also probably need a script to generate large bootstrapped data.
• Investigate orm2 node module for better usage of it's api, i.e. use chaining for complicated queries instead of find()
• Enable caching if possible.

Transactions

We need to add transaction support by utilizing transaction plugin.

Documentation

Address documentation as clarified in section 6. Code Documentation in Brivo_Labs_SAM_API-Coding_Standards.doc for both controller and model.

• The input parameters to the method must be documented clearly, we have 4 different type of input params :
  • path params : list the parameters set in the URL path
  • querystring params : list any querystring parameter
  • body params : list the body of the request in details
  • custom headers : should list any custom header read by the method
• It is important to write down a list of responses, it should include both successful and failed responses with their status code.
• It is also important to document the parameters validation info, possible values, optional or required, and default value.
• All responses must be in JSON format.

Responses

All responses must be naked.

Error Handling

When some server error occurs, it will send error in the response. It should follow the error codes responses here and return json error message (error message should be optional), note that message should not disclose any value from the passed in parameters or from database. It should only mention the problem in general or by specifying the NAME of the resource/parameter ..etc.

Use The built-in Restify Rest Errors (RestError).

In access reservation, we improved the error repsonse to include error code to help consumer application to better understand the errors.

Validation

Validation for input parameters and between callbacks must be performed as needed.

Style Checker and Correction

We have integrate with Coffeelint to force style checking against the code. Your updated code must pass coffee lint with the rules we set in coffeelint config file.

Some other coding standards.

• Enforce conditional statements to follow this pattern, It does not have a rule in coffeelint, so this needs to be manually fixed until we have a custom rule written in coffeelint. It should be used also in returning errors.
• Use async module for callbacks, it should replace each and underscore modules when dealing with callbacks and organizing code.
• Use underscore for utilize functions not supported by async , it should replace each module.

Test Cases

Using mocha framework, we want to write functional accuracy and failure test cases that address all failure/successful scenarios for each endpoint in scope. Use existing unit tests as guide for test creation.

Please note that the test cases must be documented as described above (In Documentation section)

If you have better idea and improvement to make the test directory well organized, please suggest.

Code Coverage

Use coffee-coverage  reports to produce coverage reports that help evaluate the coverage of the test cases.

Build Tool

We are using Grunt to automate running coffeelint and mocha testing.

README.dm

Readme file should be updated with configuration, and steps needed to run coffeelint and test cases.

IO Docs and Postman Doc

Update io docs and postman json files if there were any changes or a missing endpoint.

Source Code

The code is provided in challenge forums.

Final Submission Guidelines

Submission Deliverables

Patch file of the changed files. WIth text file about any note you want to mention to reviewer when testing your submission.

Final Submission

For each member, the final submission should be uploaded to the Online Review Tool.