Challenge Commit

[schaimanas]

My implementation of the platform-go-challenge

[alesr]

Hey! I'm having a look at your solution. Really clean implementation. I appreciate attention to the details. Nice work! 👍

[alesr]

Are we actually ensuring that the asset exists before creating the favorite?
In what circumstances could this check fail?

[schaimanas]

It ensures the asset exists at the moment assetRepo.Get runs. There’s a time window before favRepo.Create runs, if the asset is deleted in that gap, a race condition can occur. So Get might see the asset, but by the time favRepo.Create writes, it may already be gone.

[alesr]

What happens if the server stops running?

[schaimanas]

If the server stops running, meaning the go funct exits without the gracefull shutdown been trigger, then the error retured from ListenAndServe() would be logged but the main would not know about the server been shut down. This would lead to the app been seemingly running (DB for example been up) but it would not be able to accept any requests.

[lkslts64]

@SokratisChm Thanks for submitting the challenge, we appreciate your effort. You did a great job, with excellent architecture and design patterns, production-ready features such as HTTP server graceful shutdown, Docker Setup, structured logging, etc. Moreover, your RESTful API design and DB schema look great 💯

I would appreciate it if you could take some time to answer the following questions:

• Can you briefly explain what kinds of tests you would add to your implementation if you had more time (unit tests, integration tests, etc)?
• What kind of middleware would you add to make your app more production-ready?

[schaimanas]

@alesr Thanks so much! Appreciate the review and the kind words

[schaimanas]

@lkslts64 First of all i would like to thank you for your thoughtfull review of my project! I'm extreamly glad to hear your kind words!

Regarding the questions:

1. I would use unit tests to verify that main functions of the application work correctly (domain and usecases). This would happen by mocking out repos to produce the desired function results. Intergration tests would be helpfull to prove the application and its depedencies (DB) work correctly with eachother. I would create a test db to test the functionality of the application in order to avoid write /read on the dev db. To be honest i cannot think of other tests to put on at the moment.

2. I would add an observability middleware that produces rich in context logs to provide end to end visibility across services and a better understanding of how my endpoints handle traffic. I would also add panic-recovery middleware. I have read that there are ways to prevent a single bad code path from taking down whole processes and to handle such cases gracefull., for example, by logging the stack trace that caused the panic. This would make client behavior more predictable and consistent across the application.