72 hours!! - Topcoder Arena 3.0 - SRM problem fetching API implementation

This is a fast challenge, the timeline is short. 72 hours for submission, 24 hours for review, 24 hours for appeal and 12 hours for appeal response.

Challenge Overview

Challenge Objectives

Implement the API for fetching and listing the SRM problems, and fetching the details of each problem.

Project Background

Topcoder Arena 3.0 is the next generation Topcoder Competition Arena, which will be built with new and modern technologies. It will replace the legacy Topcoder Arena built by Java applet in 2001. The legacy Topcoder Arena is outdated and has some compatibility issues with modern operating systems. In Topcoder Arena 3.0, both front-end and back-end will be redesigned and rebuilt completely.

Technology Stack

• NodeJS + Express

• PostgreSQL

• Heroku

• Docker

Individual requirements

In the last challenge, we wrote a swagger spec for the following two API endpoints:

• Fetch and list all the SRM problems.

• Fetch the details of each SRM problem.

 

The swagger spec is attached in the forum.

 

In this challenge, we are looking for you to implement these two endpoints. You may use a starter pack from this Github account https://github.com/topcoder-platform-templates/nodejs-postgresql-rest-api. Use the starter packer is just a suggestion, not mandatory.

 

Here is the ERD of the existing data models for your reference. In this challenge, we only focus on the problem and component table.

 

problem is an SRM problem, component includes the details of the problem, like the problem statement, required method name, class name etc. 

 

Here are the detailed description of each field.

(1) problem

• problem_id: The unique ID of the problem

• name: The name of the program.

• status_id: The problem status ID

• program_text: (ignore it now, useless)

• modify_date: The last modify date of this problem.

• proposed_division_id: The proposed Division ID (Division 1 or 2)

• program_type_id: The program type ID

• proposed_difficulty_id: The proposed difficulty ID (Difficulty level, decimal)

• create_date: The create date of this problem.

• accept_submissions: The number of accepted submissions

(2) component

• component_id: The unique ID of the component

• problem_id: The associated problem ID

• result_type_id: The result type ID (Just consider it as a decimal for now)

• method name: The required method name

• class_name: The required class name

• default_solution: The text of the default solution

• component_type_id: The component type ID.

• component_text: The statement of the problem.

• status_id: The component status ID (Just consider it as a decimal for now)

• modify_date: The last modify date of this component.

 

The data of these two tables are provided in the forum:

• problem.json:  the problem table.

• component.json:  the component table.

 

Here are the detailed requirements of the two API endpoints:

1. Create the two tables in the PostgreSQL and import the JSON data.

2. You may also place other complementary files such as a README.md in the root folder (/).

3. Input validation and all the response code in the swagger spec should be implemented.

4. You should provide the Postman collection for validation

5. For authentication with the valid TC user JWT and a valid M2M token, we need to use the library https://github.com/appirio-tech/tc-core-library-js/tree/v2.6.3, you can check the usage in https://github.com/topcoder-platform/submissions-api for reference.

6. The local Docker deployment is in scope

7. The remote Heroku deployment is in scope.

8. Unit tests and e2e tests are in scope.

Important notes

• You can take the existing Topcoder v5 API code for reference:

  • https://github.com/topcoder-platform/submissions-api

  • https://github.com/topcoder-platform/tc-bus-api

Final Submission Guidelines

• The full source code of the API implementation.

• The link of your Heroku

• A README.md to describe how to deploy the API locally, remotely and verify the API