Omega Microservices / API Challenge - Endpoint Service

Welcome to the Omega Microservices / API challenge. This challenge is the second in a series of challenges where will build an application for a world leading retail hardware and software solution manufacturer.

 

Project Overview

The goal of this application is to allow retail store operators to manage and provision security for their fleet of hardware and POS software. In this series we will be building our application APIs. This will be a series of microservices built in Golang connecting to a Cassandra database. We will be creating 13 microservices in total and have already completed three of them so you will have some good examples.

 

Challenge Details

We have the following resources that will be built out as microservices:

• Customers (microservice already exists)

  • Enterprise Groups (microservice already exists)

    • Location (microservice already exists)

      • Endpoint Services

      • Terminals

        • Peripherals

          • Endpoints

            • Manifests

  • Statistics

  • Users / Groups / Roles

• Coming soon

  • Events

  • Alerts

  • Manifest Templates

 

For this challenge, you will create a microservice for the “Endpoint Service” Resource. Details about this can be found in the Dataguard_Endpoints.yaml file - this has been provided in the challenge forum and is visible only after registration.

 

As part of this challenge, you also need to provide the following:

1. A CQL file and a CSV file containing 100 records which will be used with our existing “dgestool” utility to import the schema and load the data.

2. Update the “dgestool” utility to support detection, mapping and import of the new service’s sample data CSV.

3. Unit tests that exercise your solution. Use the Go test framework for all unit tests and provide coverage report.

 

Following are points that you need to take care of:

1. Note the hierarchy and dependency in the resource. Since you are building the “Endpoint Services” resource, make sure that you have checks for referential integrity.

2. Domain data isolation: each microservice “owns” its respective Cassandra keyspace, if another microservice wants to access data that is not its own, it must do so through the foreign microservice’s API and not attempt to access the Cassandra keyspace directly.  A good example of this can be found in the locations service where the service verifies the existence of the parent enterprisegroup by creating a web service client and querying enterprisegroups microservice for the enterprisegroup in question.

3. Sanitize the input data and ensure that the microservice that you build is not prone to SQL-injection type of attacks: use parameters for querying which will also allow special characters from being interpreted as part of the CQL script.   

4. For all purposes, we strongly suggest that you follow the design and architecture of the “Locations” microservice. We will soon be correcting the “Customer” and “Enterprise Groups” microservices to follow the practices obeyed in building the “Location” microservice. Hence, refrain from using the “Customer” and “Enterprise Groups” microservice as reference.

 

Final Submission Guidelines

Submit your source code in zip file to TopCoder Online Review. Your submission must include the following:

• Detailed setup instructions
• Documentation of unit tests
• Unit test coverage report