Quartz Energy - PVT Properties Service API challenge

Challenge Overview

Challenge Objectives

 

• Java Rest API development using Spring Boot

Project Background

• Our client has developed a specific method of converting oil properties

• All the calculations are currently in an Excel workbook - our goal is to create an API to store and process the data, i.e. move the calculations from Excel into the codebase.

• In this challenge, we’ll implement the service to support the frontend UI requirements

 

Technology Stack

 

• Java 11

• SpringBoot

• MongoDB

• JUnit

 

Code access

 

The base code is available in the forums and contains only the bare project structure. Project architecture and deployment instructions are available in the project wiki page (see the link in the forums)

 

Individual requirements

 

• Calculation endpoints
  This is a set of CRUDL endpoints for managing input data sets and the calculation results. Create/update endpoint will just call the calculation service and save the response in the database. Get/list/delete endpoint will operate on the local data in the database - they won’t call the calculation service. Inputs to the create/update data endpoint are the same as what calculation service requires (see sample swagger for details). Response will be the same as that of the calculation service (except that the data id is the id of the db record created by the service, not the id returned by the calculation service). Well name and sample number should be unique combination - creating duplicate calculations should throw an error. List endpoint will support filtering and sorting by well name, sample number and date.

•  

• Well name and sample number lookup endpoints
  This endpoint will return unique well names and will have an optional name filter (well name LIKE filter*) and sample number filter (sampleNumber LIKE filter*) - from the calculation results collection.

NOTE: in this challenge we only have a swagger spec for the Python backend, not the API itself, so you will need to create mock service for testing/verification

For reference, this is the frontend that will use this service (marvel app link shared int he forums). Csv report is generated by the frontend.  

General requirements

 

• Unit tests are required for all services (not the controllers) and tests should validate that the operation works correctly and the result is correct.

• All database collection names should be prefixed with “API_NAME_SERVICE”

• All configuration parameters should be extracted to the configuration file. Sensitive configuration parameters should be set from environment variables (DB URL, credentials, etc). All environment variables have to be prefixed with “API_NAME_SERVICE”

• Please make sure your code is well-documented. Please make sure it is well-engineered but not over-engineered (YAGNI and KISS) solution. We're looking for well-structured and tested code. Well-structured code follows good design principles like the SOLID principles and well-tested code has comprehensive unit tests.

What To Submit

 

• All source code (git patch)

• Deployment guide

• Postman collection containing sample calls for all endpoints (success/failure)

• Verification guide - how to set up the environment, start the API, and verification screenshots

• The unit tests coverage report

 

Scoring Methodology

 

Contest Specification Requirements(60% weightage)

 

·       Have all major specification requirements been met?

Score: 0-9

Major requirements are:

·       all endpoints are implemented correctly and return the correct data and codes, etc,

·       all DB models are defined and contain correct attributes and data types

·       Unit tests - minimum coverage 80%

                      Have all major specification requirements been met?

Score: 0-3

Minor requirements are:

 

·       Postman collection

Best Practices & Comments(30% weightage)

 

·       Does the submission follow standard best practices?

Score: 0-3

This section includes the code style, linter, patterns usage, code comments

Please make sure your code is well-documented. Please make sure it is well-engineered but not over-engineered (YAGNI and KISS) solution. We're looking for well-structured and tested code. Well-structured code follows good design principles like the SOLID principles and well-tested code has comprehensive unit tests.

 

Deployment and verification guide (10% weightage)

 

·       Does the deployment guide contain everything needed to successfully configure and deploy the API?

Score: 0-3

Final Submission Guidelines

See above