Nest: HttpService should return promises

[patrickhousley]

I'm submitting a...

[ ] Regression 
[X] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

All methods in the HttpService return Observables.

Expected behavior

All methods in the HttpService should return Promises.

Minimal reproduction of the problem with instructions

N/A

What is the motivation / use case for changing the behavior?

Promises are meant to be used when a single value/event is expected while Observables are meant to be used when a continuous stream of values/events are expected. Since HTTP calls always produce a single value, we should not wrap these as Observables. Additionally, Promises are not compatible with test schedulers making testing more difficult. See here.

Environment

Nest version: 4.6.4


For Tooling issues:
- Node version: 8.9.3  
- Platform: Windows  

Others:

[chanlito]

I totally agree with this +1

[patrickhousley]

Sorry but I am going to have to reverse my position here. While the statements in the original issue post above are valid, changing the HttpService to return Promises pushes the problems of testing code that mixes Observables and Promises off to the developers using Nest. TL;DR keeping the method return values as Observables mean developers can mock the methods to return Observables using a test scheduler.

[kamilmysliwiec]

@patrickhousley

Sorry but I am going to have to reverse my position here. While the statements in the original issue post above are valid, changing the HttpService to return Promises pushes the problems of testing code that mixes Observables and Promises off to the developers using Nest. TL;DR keeping the method return values as Observables mean developers can mock the methods to return Observables using a test scheduler.

Exactly 🙂 Moreover, Observable operators are more descriptive than just a chain of then() calls.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.