ChannelMeter Coding Test

Link to Loom Demo

Notes

How to Use The API

It's straightforward to get set up with this application.

Simply run the app with the make run command (see Makefile,) then feel free to use curl to query the endpoints as prescribed. See the below commands for examples.

curl 127.0.0.1:3000/exams/0
curl 127.0.0.1:3000/exams
curl 127.0.0.1:3000/students/Alda.OConnell
curl 127.0.0.1:3000/students/

Testing

Please see the make test command.

What's inside?

A quick look at the top-level files and directories you'll see in this project.

- build
- config
- controllers
- db
- docs
- middlewares
- server
- tests
- utils
- Dockerfile
- Makefile
- go.mod
- go.sum
- main.go
- .gitignore
- README.md
  1. /build: This directory contains the binary after a build

  2. /config: This directory contains the viper configration and the property files.

  3. /controllers: This directory contains the controllers that the router/handlers are configured to call.

  4. /docs: Directory for swagger files.

  5. /middlewares: This directory is used to house the middlewares used by the controllers.

  6. /db: This directory is used to house code related to the management of data in memory.

  7. /server: This Directory houses the router and service files which configure the route and start the server

  8. /tests: This directory contains all the tests for your application and get kicked off by:

     make test
    
  9. /utils: This directory contains all the util classes used throughout the app.

  10. Dockerfile: This file contains the buildsteps to build your image using a multi stage build. It is currently using a scratch image to keep it lightweight.

  11. Makefile: This file allows the use of make to run tests, build locally, and is used to build in the pipeline. This can be expanded as needed

  12. go.mod/go.sum: These files are generated by Go Mod dependency management and can be learned about in the documentation link provided above.

  13. main.go: This file is the starting point for the application, which starts the server.

  14. .gitignore: This file tells git which files it should not track / not maintain a version history for.

  15. README.md: A text file containing useful reference information about your project.

golang-coding-challenge

Prompt

You may build this application in Golang/Python. We would say try with Go first but if you get stuck you can move to Python. You may also use any open-source libraries or resources that you find helpful.

At http://live-test-scores.herokuapp.com/scores you'll find a service that follows the Server-Sent Events protocol. You can connect to the service using cURL:

curl http://live-test-scores.herokuapp.com/scores

Periodically, you'll receive a JSON payload that represents a student's test score (a JavaScript number between 0 and 1), the exam number, and a student ID that uniquely identifies a student. For example:

event: score

data: {"exam": 3, "studentId": "foo", score: .991}

This represents that student foo received a score of .991 on exam #3.

Your job is to build an application that consumes this data, processes it, and provides a simple REST API that exposes the processed results.

Here's the REST API we want you to build:

  1. A REST API /students that lists all users that have received at least one test score
  2. A REST API /students/{id} that lists the test results for the specified student, and provides the student's average score across all exams
  3. A REST API /exams that lists all the exams that have been recorded
  4. A REST API /exams/{number} that lists all the results for the specified exam, and provides the average score across all students

Coding tests are often contrived, and this exercise is no exception. To the best of your ability, make your solution reflect the kind of code you'd want shipped to production. A few things we're specifically looking for:

  • Well-structured, well-written, idiomatic, safe, performant code.
  • Tests, reflecting the level of testing you'd expect in a production service on the 4 API endpoints
  • Good RESTful API design. Whatever that means to you, make sure your implementation reflects it, and be able to defend your design.
  • Ecosystem understanding. Your code should demonstrate that you understand whatever ecosystem you're coding againstÑ including project layout and organization, use of third party libraries, and build tools.

That said, we'd like you to cut some corners so we can focus on certain aspects of the problem:

  • Store the results in memory instead of a persistent store. In production code, you'd never do this of course.
  • Since you're storing results in memory, you don't need to worry about the ÒopsÓ aspects of deploying your serviceÑ load balancing, high availability, deploying to a cloud provider, etc. won't be necessary

Please try to complete this task within a week from receiving it. Once you are finished provide a readme with the final code that include: How to run the code, How to use the api and any other libraries or code needed to run this test.