The first endpoint, POST /articles handle the receipt of some article data in json format, and store it within the service. The article will get an id and the date will be the datetime the article was received.

POST Payload

    {
          "title": "latest science shows that potato chips are better for you than sugar",
          "body" : "some text, potentially containing simple markup about how potato chips are great",
          "tags" : ["health", "fitness", "science"]
    }

The second endpoint GET /articles/{id} return the JSON representation of the article.

The final endpoint, GET /tags/{tagName}/{date} return the list of articles that have that tag name on the given date and some summary data about that tag for that day.

Download:

    $ go get github.com/gambarini/articleapi

You must have the following installed to run the API server:

• golang 1.10 (but any older version should be ok)
• docker

From the articleapi folder execute the run script:

    $ run.sh

It will take a while to initialize the following:

• MongoDB docker container.
• Start the api server

If it all work, the API should be running on localhost:8000

Just Ctrl+C to terminate the server when you done. The script will cleanup the containers.

Dates are always in the format yyyy-mm-dd

The POST /articles endpoint ignores any ID and Date posted in the payload. Both values are generated by the API based on the time the article is received.

The GET /tags/{tagName}/{date} endpoint is not considering high traffic situations and is quering the articles database directly.

A better approach for scalling the tag queries would be building it as a separeted service with its own tags database. Then the database would be populated every time a new article is created (by services choreograph), resulting in a eventual consistent tags database offering better throughput for tags service.

The only Unit test added was for the FindTag method in the ArticleRepository. This api was build in a bit over a hour and only tests for the more complex code were considered.

For the repository tests that require direct database access to make sense, a mongoDB docker container is started and managed within the test execution. Since mongoDB has the advantage of quick initialization without any configuration necessary, this approach to unit test is very favorable. It provide fidelity by running tests against the real DB while keep unit test execution farly quick.

All endpoints were tested with Postman during development and a Collection file was added to the repository for reference.

The lack of unit testes is in no way the ideal case, and is only consided due to the short time of development.

To improve execution time on the FindTag method the count query is executed in a go routine, concurrently to the main query fetching the articles.

The project is structured for a separation of concerns, with the api server package containing the HTTP server logic, and the repo package abstracting the Database with a Repository Pattern. Finally the model package holds the objects that are part of the domain of this service.

Its useful to notice that in case of tests to the server package were added, the Repository abstraction would provide a easy way to Mock the Database. All by adding a ArticleRepository interface.

The article api is designed to be deployed as a microservice and can easely be run in a docker container.