Props to you guys for open sourcing it!
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.
It makes sense that awkwardly hard coded hacks like this will exist in a startup's piece of software. But it's possibly full of similar things that might take a lot of effort to find, much less fix.
When money is running out and deadlines are looming its hard to have the discipline to not do stuff like this, and a startup's goal tends not to really be to build open source software for everyone to use anyways, so I'm not surprised something like this might exist.
But why would anyone use this?