The UI displays the following data in a table format when the owner/organization and repository name are entered in the form displayed on the home page:
- Total number of open issues
- Number of open issues that were opened in the last 24 hours
- Number of open issues that were opened more than 24 hours ago but less than 7 days ago
- Number of open issues that were opened more than 7 days ago
- You can find the Live Application by clicking on this link.
- The platform of choice for deploying the application is Heroku.
- gorilla/mux - For routing purposes
- google/go-github - Client library for accessing the Github API V3
- gomodule/redigo/redis - Client library for communication with Redis
- streadway/amqp - Client library for communication with RabbitMQ
- For dependency management, I am using golang/dep
- As mentioned, I am using go-github library which does the excellent job of providing a higher level API to access the Github V3 API.
- Initially, I created a github client object using the structures provided by the go-github package. Since the Github API only allows a certain number of unauthenticated API calls, I created a personal auth token which I use to authenticate the client.
- Next, I passed in various options related to the features discussed above to fetch the required information about a particular repository owned by any user.
- After that, I created four routes, one for the index page where a form with two input fields, namely owner and repository, one for creating a worker job where the main issues fetching thing happens, another for checking the status of the completion of the job and the last for actually displaying the data to the user.
- When the relevant information is entered, for example, owner as smartystreets and repository as goconvey, the form data is then directed to a /issues API which does the job of calling the actual Github API for fetching the information about the repository by submitting the job to a RabbitMQ queue. This particular job is handled by a background worker which runs as a separate process and it fetches the job to be performed from the RabbitMQ queue.
- To store the data which can be later fetched by the client side, I am using Redis.
- As some requests take a lot of time process and the request gets stuck, the client sends a request to the server at an interval of 5 seconds to see if the job has been completed or not. If it is done, the client routes the user to the display page where all the results are displayed.
- I did not particular follow TDD which I should have, but intend to write tests for all the functionalities given more time.
- Also the UI is pretty basic and not very intuitive.
- A Makefile would be nice to have as it would ease the setup of project on any computer, thereby supporting the concept of automation.
- There is no mechanism present to prevent a large number of requests from any user, which might lead to a server crash as the server is not optimized to handle a large number of requests.
- Implement caching of issues data for a small period of time which would actually save time and resources to fetch the resources from Github.
- Limit the usage of this service by allowing only authenticated clients to make requests and fix a quota for them, so that the API does not get abused.
- Optimize the server to handle a large number of requests and also not accept requests if there is an overloading of requests to it.
That's all, folks! :D