1

I have a nodeJS library, where I'm coding a certain functionality, which will call a SOAP API to get information.

I want that people can use the library easily. So that they can just call:

library.requestThatService(parameters ...);

And the library should handle all the dirty work behind scenes. What I want the library to do is to first possibly validate the parameters given. Then construct the message to be sent based on the parameters (serialization?), create signature etc... And finally, call the soap API with a soap client including the message created and signed before.

Now I'm thinking of using javascript Promises for that. I'm not sure whether I should wrap the whole library.requestThatService(parameters ...) function to return a promise, and then use fail and success function (.then in practise). What I'm really asking is, that whether I should only use async for the actual async API call, or for the whole library function? Instead of making the library call to return a promise, I could add a callback function to it. Then inside the library function, I should use async promises only for the part where the SOAP request is sent. And not include validation and message creation for the async part, since they are not async operations.

The SOAP client might return a promise by itself already. So then I would have two promises floating around a function, and I'm not sure if that is a good idea at all really. Then one of those promises wouldn't be resolved or rejected.

Ville Miekk-oja
  • 18,749
  • 32
  • 70
  • 106
  • 2
    `whether I should only use async for the actual async API call, or for the whole library function?` - yes, which ever you chose is fine - as long as you don't think that you can somehow make asynchronous code synchronous – Jaromanda X Aug 10 '16 at 07:25
  • Could you reason why both options are fine? Since then I would include some operations that are not really async. And then I have two promises in one function, and that just doesn't sound good at all – Ville Miekk-oja Aug 10 '16 at 07:26
  • Async API functions should return a promise as they are simply more capable and flexible than a plain callback. Non-async API functions should return whatever normal synchronous return value makes sense. You should never need to return two promises. You might use two promises internally if you have two async operations running in parallel, but they would be combined into a single returned promise that represents when both are complete as with `Promise.all()`. – jfriend00 Aug 10 '16 at 07:29
  • if you want to use Promises, use them correctly, and in most cases you wont have `two promises floating around a function` - you'll be using Promise chains as they should be used.- if you don't understand this, or if Promise chains are not the optimal solution, use callbacks, just like the rest of the standard nodejs does. Promises are not always the answer to asynchronous programming, they are a tool, and like any tool, are best used when they are the best tool for the work at hand – Jaromanda X Aug 10 '16 at 07:29
  • Are you suggesting, that I could actually use promise for the validation and signature part, if I just create a promise chain? I could modularise the validation and signature to their own functions, and let them return a promise, that I can chain to the actual API call? But because the validation and signing are not async operation, is it correct to use promises for them? – Ville Miekk-oja Aug 10 '16 at 09:17

1 Answers1

2

Should I only use async for the actual async API call, or for the whole library function?

Yes - always promisify at the lowest level! You will want to use power of promises yourself, don't you?

The SOAP client might return a promise by itself already. So then I would have two promises floating around a function, and I'm not sure if that is a good idea at all really.

Indeed, wrapping a promise-returning call in another new Promise call is an exceptionally bad idea even.

Community
  • 1
  • 1
Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • This feels right again, but it doesn't fully answer the question yet. Should I then just append a callback to the library's main function? So that the library function would not return a promise by itself? But the api call done inside the library's main function would return a promise, but that promise would not be the return value of the main function. Since the validation and signing can also fail, and then they would not return a promise. – Ville Miekk-oja Aug 10 '16 at 09:33
  • No, you would use promise chaining on the api call just like you expect your users to use promise chaining on your library. If the validation and signing can fail without being asynchronous, have a look [over here](http://stackoverflow.com/q/35856041/1048572) – Bergi Aug 10 '16 at 09:39
  • Okay, so it is okay to return a promise from synchronous operations. I will make it so the whole library will return a promise, even some functions executed by the library are not async operations. – Ville Miekk-oja Aug 10 '16 at 10:27
  • 1
    Yes. "sometimes synchronous" is a [very bad idea](http://stackoverflow.com/q/38158830/1048572), so we *always* return a promise. – Bergi Aug 10 '16 at 10:41