Quartz Energy - Merge XRD API

Challenge Objectives

 

• Python Rest API development using Flask framework

• Update calculation endpoints

 

Project Background

• We have two related APIs that use similar underlying data to calculate the outputs

• In this challenge, we’ll merge them into one codebase

 

Technology Stack

 

• Python 3

• Flask

• Flask-Restplus

• MongoDB

 

Code access

 

The base code is available in the forums and consists of 3 code bases:

• XRD api - this is the base code - we want to merge everything into this codebase

• XRD CEC api - this is the API that we want to merge into XRD codebase

• Optimization library - used by XRD api - no changes are required here

 

Individual requirements

 

1. Fix issues in XRD CEC calculation

   1. Use linear interpolation to get SmectitePcnt when the exact value isn’t provided (xrd_cec_api/service/calculation_service.py:6) - the current code is just looking for the closest value. For example, assume that we are looking for percentage=30, and only keys 10 and 40 exists in SmectitePcnt. Then using linear interpolation, SmectitePcnt[30] = SmectitePcnt[10] + (30-10) * (SmectitePcnt[40]-SmecticePcnt[10]) /(40-10)

   2. clayMineralogy should be a dynamic list that allows adding more minerals (xrd_cec_api/service/calculation_service.py:44-46). Current api is just using `chlorite`, `kaolinite`, `illiteMica`. We should instead iterate over all the minerals that are passed as clay minerals for calculating cec.

 

2. Merge XRD CEC into XRD codebase
   Both APIs contain similar endpoints (data import, create, read, update delete) and a couple of endpoints specific to XRD. Data import endpoints for both APIs require a matrix of minerals and some additional data (xrd api requires kerogenWeightPercentage , startingDensities, lowerBounds, upperBounds , while CEC api requires wClay, porosity, density, smectiteInMxlIS). We want to update the data import endpoint to support uploading both XRD and CEC values - minerals data will be uploaded anyway (required), and then XRD and/or CEC additional data is provided in the body (both or just one of them). Based on the provided input data, validation should be updated to return correct error messages in case of missing values for either variant of the input data. Another difference in the input data handling between these two apis is that XRD loads minerals data from a CSV file, but CEC loads it from the json payload in request body - we should standardize here on using the CSV file as input for minerals data.
   Calculations for CEC should be updated to use only minerals that have is_clay=true (remaining minerals will be ignored for CEC calculations).
   XRD calculations that calculate individual steps will remain as is and will only return XRD calculations (only update them to return an error if the data is for CEC and not XRD)
   Get data endpoint (GET /data/:id) should return both XRD and CEC input data
   Create a list data endpoint (GET /data) that will filter the records from database (this endpoint should be migrated from the xrd cec codebase)

General requirements

 

• Unit tests are required for all endpoints.

• All endpoints should be annotated with Swagger annotations and swagger UI should be served by the API.

• All configuration parameters should be extracted to a common settings module. Sensitive configuration parameters should be set from environment variables (DB URL, credentials, etc).

• Please make sure your code is well-documented. Use the following style guides Google Python Style Guide, Python Style Guide, and Docstring Conventions. Code linter is required. 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.

• The code should be implemented using Python3 only.

 

What To Submit

 

• All source code

• 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

·       Swagger annotations

 

Best Practices & Comments(30% weightage)

 

·       Does the submission follow standard best practices?

Score: 0-3

This section includes the PEP-8 code style, linter, patterns usage, code comments

Please make sure your code is well-documented. Use the following style guides Google Python Style Guide, Python Style Guide, and Docstring Conventions. Code linter is required. 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