Skip to content

oforero/interview-api

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

42 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Introduction

The exercise called for a voting application in the spirit of Digg/Reddit.

I focused not only on writing the code but creating a deployable app.
I did it using Go, Docker and Kubernetes to build a minimal but complete implementation.

Links

Design

  • I decided to split the application into two main components, an API server and a Web server
  • I started by creating a Go HTTP service using mostly standard libraries; the API server uses standard Go data structures as required.
    • Code in src/api
    • The topic is represented as a struct, without any fields exported and a custom JSON marshalling method
    • The topics have a Unique ID that is generated using a third party library
    • The topics are maintained in a Go slice, which is kept in descending order. The key for the ordering is upvotes - downvotes
    • An index of topics is maintained in a map, it maps Topic unique ID to the location in the array.
  • Soon after the initial code was compilable I created a build in Travis CI to keep a CI discipline.
  • The second component is a web server delivering plain HTML pages to the clients
    • Code in src/web
    • I wanted to split the code to access the API service from the HTML app routeing, this forced me to have a main directory for the main entry point of the web server
    • I used Sling to communicate with the API service
    • HTTP requests are routed using the standard Go net/http package
    • The current application has only one route returning an HTML page
    • The other routes call the relevant API and redirect the client to the HTML generation url
    • The HTML is generated using ACE and the results of listing the topics using the API service

Continuous Delivery

After having a minimally running API application, I created a Docker container meant to run locally on my laptop. This was enough to make some initial testing but deploying laptop build containers is not a good idea under any circumstances.

I decided to use Google Container Engine to deploy the app for review, which made Google Container Builder an ideal solution to build the containers for deployment. The containers for the API and Web services are built independently and are triggered by GIT Tags (api-, web-), at the moment I do not have a trigger from Travis to Google Container Builder.

In this way after a Travis build is successful, the Containers are build and put in the Google Container Registry by tagging the relevant commit and pushing the tag to GitHub.

Deployment to a Google Cloud Kubernetes Cluster

The application is deployable using kubectl, provided the Google SDK is installed and configured to manage a Kubernetes Cluster. The current deployment scripts are standard kubernetes files, but accessing the image requires access to Google Container Registry.

$ kubectl create -f deploy/api-pod.yml

$ kubectl create -f deploy/api-svc.yml

$ kubectl create -f deploy/web-pod.yml

$ kubectl create -f deploy/web-svc.yml

Missing Feature / Improvements

  • The application still doesn't enforce a message limit as requested
  • Modify the topology to have multiple web application pods behind a load balancer
  • Improve the Rest API, for example adding support for autogenerated documentation
  • Add more tests and test Examples to the API
  • Modify the web app to generate table on the browser and get only the data instead of creating a full HTML page each time
  • Add tracing/logging

About

Web Services for a very basic reddit clone

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages