Topcoder Terms API part1

Challenge Objectives

 

• Build base code for the new Topcoder Terms API

Project Background

 

• Topcoder services keep the terms of use in now legacy Informix database. Topcoder v2 API provides access to some of the terms management features. This project aims to build a standalone Terms microservice by following Topcoder v5 API standards  

• Follow-up challenges will build new endpoints. Once the API is built, deployed and tested, we will create migration scripts, update all apps and services that depend on the current v2 API

 

Technology Stack

 

• NodeJS

• Postgres

• Sequelize

• Express

 

Code access

 

We’re creating a new service in this challenge so the codebase setup is your job. We do wan’t Topcoder services to have similar structure so please follow the project code structure of a sample v5 API service - submissions api

 

Individual requirements

 

The v5 Terms api we’re building in this challenge will essentially extract features from the v2 API. The following API endpoints have to be migrated in this challenge:

• GET /terms/{termsOfUseId}

• POST /terms/{termsOfUseId}/agree

• POST /terms/docusignViewURL

• POST /terms/docusignCallback (and the related Docusign Connect Listener)

 

As an overview, these are the tasks that should be done for the new service:

1. Create data model and database structure to support the terms persistence
   The current terms are stored in informix database and v2 api uses stored queries to access the data - data model should be migrated to Postgres and data access should be done using Sequelize. Terms should be identified by ids, but using raw database ids should be avoided so we can have stable terms identifiers in local, dev and production environments (should not rely on import scripts/sequences setting the correct ids)

2. Create terms service and controller layers
   This includes porting the business logic from the v2 api

3. Build unit tests

 

Docusign Connect Listener can be left as a standalone service, but should be moved to the v5 API codebase.

 

General for all requirements

 

Use controllers/services model for the new API. Logging is required for all services. Unit tests are required and should be ported from the v2 api codebase (test for the same use cases) and also add tests for data access. Create a new swagger file for the API, and create Postman scripts for validation.

Submission Guidelines

• Submit a Readme with details on how to configure, build, run and test the service

• Submit Swagger and Postman files for verification

Final Submission Guidelines

see above