CRM - Benefits Backend API

Challenge Overview

We are building an internal web application for a client, to be used by their customer service associates. This application will be divided into frontend and backend. This is the first challenge of a series of challenges to build the benefits module for the application.  
 

Goal of the challenge

The goal of this challenge is to start building the benefits backend API from the design specifications.
 
Technology and Framework details

• NestJs
• Typescript
• NodeJs 12.x

Individual Requirements

Use the Benefits Tech Spec.pdf as the starting point (found in the forum). The tech spec references lots of json files and will direct you
where to find corresponding logic in other .txt files that can also be found in the forum

This challenge needs to implement these 4 API endpoints:.

1. GET getContractsByIoi
2. POST getMedicalBenefits
3. POST getDentalBenefits
4. POST getPharmacyBenefits

The eventual UI will use data from the first request to build out the next 3 POST requests, so please ensure that the request flow is well documented in your submission, and covered explicitly by at least 3 separate unit tests
In the UI, each page contains a dropdown with coverage dates from the first request that will allow the user to create single POST requests with new date params.

A sample API project from a different module will be provided in the forum, for reference.

General requirements

• You are required to use starter-template provided in the forum.
• The REST API has only four endpoints to be implemented. Documentation and sample responses will be provided in the forum.
• No database access should be used, instead we'll use JSON files on the file system.  The code should be written to allow changing from JSON files to a real database in the future.  Please ensure that the data retrieval access is well encapsulated and easily switched.  Please build the models and API correctly - don't just return the JSON from the file system.  Have a look at the sample project for an example.
• A Swagger file should be created that covers the API.  Note that accurate documentation of the API via Swagger is required and a major requirement, and the individual calls, objects, and fields should be documented in the Swagger file in good detail.
• Code must pass eslint, without duplicated code
• Clear, descriptive internal code documentation is required
• Unit tests for the services are in scope (check response and business logic).  Please ensure you provide documentation on how to generate a coverage report.  90% coverage is required.
• No authorization for the endpoints is required for this challenge
• 3rd party libraries are generally allowed, but they should be MIT or BSD licensed.  If you want to use a particular library that isn't part of the given API starter template, please get approval in the forum.

Scoring guidelines

Major requirements:

• REST API is implemented per the spec
• Swagger file is included and well documented
• Code passes eslint
• Unit tests cover the API properly (90%) and coverage report are included

Minor requirements:

• Internal code documentation is clear and complete
• Data access is well encapsulated and will be easily swapped for a real database

Submission Guidelines

Please submit:

• Backend source code
• Unit test source code
• README.md covering the environment requirements, deployment, and how the tests are run
• Validation.md covering how to validate each of the individual requests and generate the coverage report.
• Swagger file

 

Final Submission Guidelines

Please see above