Omega Microservices / API Challenge - Endpoints

Welcome to the Omega Microservices / API challenge. This challenge is the fifth 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 six 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 (microservice already exists)

      • Terminals (microservice already exists)

        • Peripherals

          • Endpoints

            • Manifests

  • Statistics

  • Users / Groups / Roles

• Coming soon

  • Events

  • Alerts

  • Manifest Templates

 

For this challenge, you will create a microservice for the “Endpoints” 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 “Endpoints” 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.

5. You are developing microservices. As such, we expect that your submission for the Endpoints microservice should be independent of the other existing microservices. Under no circumstances should any of the microservice be dependent on the other. Do not create any common code outside of the microservice that you are working on. This may result in redundant code that is present across all the microservices and we are fine with that.

Keep in mind that microservices architecture dictates that each service should be able to run completely independently of any other service. Based on this, you will want to ensure that any common tools used in multiple services appear redundantly in each microservice. We cannot stress this enough.

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