Register
Submit a solution
The challenge is finished.

Challenge Overview

Challenge Overview

We are building an internal web application for a client. This application will be divided into frontend and backend, and those challenges have completed.  This current challenge will tie the two together, so that all mock data is removed from the frontend and the data comes from the backend service calls directly.

Goal of the challenge

The goal of this challenge is integration the updated UI with the backend services.  Both code bases will be available in the forum.

Technology and Framework details

Supported Browsers

  • Chrome
  • IE 11 (MAJOR requirement)
  • Edge

Individual Requirements

Use the Benefits Tech Spec.pdf as the starting point. It references lots of json files as will direct you where to find corresponding logic in other .txt files.  Most of this should already be implemented, but it wouldn't hurt to double check this.

This challenge needs to use these 4 API endpoints:.

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

The UI will use data from the first request to build out the next 3 POST requests, so please ensure this is well documented in your submission.
In the UI, each page contains a dropdown with coverage dates from the 1st request that will allow the user to create single POST requests with new date params (see Date Selection section below).

Service integration

All mock data and mock data files need to be removed from the UI / frontend and replaced with actual service calls to the backend services.  If any data is missing in the UI responses, you can post in the forum and ask for mapping help.  You can keep the mock files in the backend, but your implementation must follow the business rules.  The business rules are in scope and if you find issues in the backend services, you must fix them.

The benefits accumulation rule endpoint will need to be added to the backend, as documented in the benefits tech spec documents in the forums.

Date selection

The only thing that can remain mocked is the date selection values.  From the client:  We'd like the community to just populate the drop down with dummy dates so there is no need for benefit api updates. We will add the logic to populate dates once the code is in house.

Sample data

You should provide updated sample files (for the backend) to allow for further validation of the various UI elements to ensure that things load properly.

Note that Contracts-Response.json is the data returned from the enterprise endpoint. Contract Summary Details.txt has the rules for pulling data from the enterprise response and mapping it to UI fields. The client did not define a UI response object for this one but you can model one based on details you find in the .txt file.  In general, {CoverageType}-RawResponse.json represent data returned by the enterprise endpoints. BusinessLogic.txt tells you where to find data in the rawresponse files that will go to the UIResponse.json. The labels may be different but for example: Deductible are in the accumulationRule arrary with a sectionId of 4. There you can then set the "type", "inNetwork", "amountSatisified".

General requirements

  • You are required to use starter-template provided in the forum.  This is already done in the backend services, but you shouldn't introduce new dependencies or make changes to the template
  • For the services, no database access is 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.
  • Code must pass eslint, without duplicated code
  • Clear, descriptive internal code documentation is required
  • Unit tests for the services is in scope (check response and business logic).  Please ensure you provide documentation on how to generate a coverage report
  • 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.

UI Requirements


The UI is *in scope*.  You should not break anything in the UI that's currently working properly (major requirement).  You are responsible for testing the UI in the supported browsers to make sure you don't break anything.  If you do find an issue, please raise it in the forum so we can track it to ensure you aren't marked down for the problem in review.

Unit tests


The backend API must be covered at 95% *per file*.  This is not an overall metric, but we are requiring that each individual file must have 95% coverage, or better.

Deployment

The UI is currently deployable to Heroku.  You must not break that deployment, and you should support Heroku deployment of both the backend and frontend pieces (minor requirement)

Scoring guidelines

Major requirements:
  • REST API is implemented per the spec
  • Code passes eslint
  • Unit tests cover the API properly and coverage report are included (95% required)
  • All mocks removed and UI is now using the backend services
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

  • Backend 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, the UI and it's various states, and generate the coverage report.

 

Final Submission Guidelines

Please see above

ELIGIBLE EVENTS:

2020 Topcoder(R) Open

Review style

Final Review

Community Review Board

Approval

User Sign-Off

ID: 30127622