Thanks for the question - for clarity, this is the file I'm referring to in this reply: https://github.com/Viveckh/Veniqa/blob/develop/shopping-server/services/

Thanks for the question - for clarity, this is the file I'm referring to in this reply: https://github.com/Viveckh/Veniqa/blob/develop/shopping-server/services/catalogService.js https://github.com/Viveckh/Veniqa/blob/develop/shopping-serv... 1. The service is a leaky abstraction, it knows about HTTP status codes and presumably the response body format. The point of separating concerns is to make code reusable, HTTP response codes don't make sense outside of a HTTP call. Similarly, any calling code needs to know that `sortRule` is expecting a MongoDB sort parameter. 2. The control flow is super unclear due to mixing async/await and Promise API coding styles. The `.catch()` call on the promise chain means that the `catch` block will never be hit and the API will always return OK, with the error object exposed to the client in the `responseData` - likely exposing implementation details about the server via the stacktrace on the error object. There are other nits I could pick, but those are the most important issues and my other criticisms are more a matter of preference.