##Thoughts I spent about 1 hour and 15 minutes on this, mainly because I haven't used postman in a while and was getting back into the swing of things with it. I focused more on the actual API, rather than how to store the data & dockerisation as the spec seemed to be focused on the API itself. Ideally I would have implemented the data layer using Dapper & postgresql, I would have also included docker / docker-compose support as well as integration tests.
I focused mostly on implementing following SOLID principles and ensuring best practices are used.
Please read the following trade-offs.
##Trade-Offs
###IRepository implementation The MemoryMessageRepository is obviously not ideal but as the focus was on the API I chose this trade-off to save time. Given more time this would be implemented using a database store. Also the current implementation isn't thread-safe, I have implemented using Task + async as the database layer would ideally implement the async methods on the db connection.
###Async Enumerable Ideally the get method on the controller would be implemented using IAsyncEnumberable. This is fairly new so I would need to read up the documentation to implement so didn't have enough time.
###Id as guid I went ahead and used a Guid on the service layer and below. I have previously added support for the Guid on the controller level of an application but it requires a large amount of middle-ware, so I decided against this. This is why I have built the DTO / parsed the inbound string Guid. This should be generated by the data layer on insertion.
Automapper or similar could have been used to properly map the inbound DTO with the database object.
###Docker / Docker compose I initially thought to add docker and docker compose support to the application, this would have allowed an ecosystem to be built and allow the solutions to be shipped with a database technology to back it. Obviously the networking aspects of docker to allow integration testing would have taken more than an hour so this was traded off.
###Test cases Due to the lack of time I have also only tested the happy path. At the controller level, I would ideally have tested the error handling + logging. Factory level is missing unit tests Constructor tests are missing Repository are missing individual tests, would be integration tests for a proper implementation.
###Postman I have tested all implemented endpoints on postman, I haven't included the test scripts for these as they are very simple tests.
###Documentation Class / Interface level documentation has been skipped for this task. The code is pretty simple and self documenting so it shouldn't be an issue.
###Dependency injection Ideally the program / start up classes would be cleaned up, along with the DI container usage. I've had to keep everything as a singleton, rather than transient, which isn't ideal, but this is due to not persisting data in the data layer.