https://netsuiteprofessionals.com logo
Join Slack
Powered by
Has anyone tired server side `Promise` objects usi...
# suitescript
c
Has anyone tired server side 
Promise
objects using a 3rd party library? Not the pre-baked ones offered in the 
N
libraries. Even if they run synchronously, there would be a ton of immediately reusable 3rd party libraries that would be useful. Just wondering what others have tried?
s
You'd likely have to swap out the 
Promise
implementation any of those 3rd party libs rely on. I think I've done that a couple times to get libs working that used promises, even though I didn't need them.
b
surprisingly ive actually gotten some of them to work in 2.1
s
did you have to replace the 
promise
implementation @battk? And if not, how are Promises implemented server side in 2.1? just as short circuit to sync calls?
b
the Promise global exists in 2.1
so no replacement needed
s
when running such code, have you observed that the Promise implementation just immediately resolves (synchronously) or do you suspect something actually async going on behind the scenes?
b
the native netsuite modules that use promises act a little weird
i suspect because the server running the code is only allowed one i/o connection at a time
so you get code that runs async in sync order
s
have you run into a use case where you have used a promise server side, then run off and done other code, then the promise resolves later?
I think we've discussed it before, but goes back to finding real world use cases where async will help an otherwise sequential process.
b
dont remember, I dont use 2.1 in general and i was weary of the weirdness
however there is a chance of chris getting his 3rd party libraries to work if they dont use any browser or node specific code
s
yes, the catch usually being they DO use either browser or node code
you may be able to get away with stubbing 
setTimeout()
b
im actually not sure how you stub that without writing code that is synchronous
s
yes, you'd make it synchronous on purpose, since that's the execution model the library is going to live in anyway
in other words, in my use cases it's been adequate to short-circuit any async behavior in a library to synchronously call under the covers because I'm not really needing the async behavior.
the main use case that comes to mind where actual async behavior would be useful in server-side scripts is if you wanted to simultaneously save or load several different records. That doesn't come up too often for me.
most often, I need the save or load of record 1 to complete before I continue on with record 2 as the logic needs info from record 1 to apply to record 2. Boy that sounds more convoluted than it is.
if as you obverved, i/o is all single threaded and the script has a single entrypoint, I don't see the advantage to having 'async' complexity for no gain.
@Chris sorry to drift away from the topic, but did you have a particular library in mind you wanted to use with NS?
c
I've been trying to get the plaid api working. Sadly, I went with 2.x b/c I had problems with 2.1 awhile back and didn't want to be troubleshooting 2 issues at once.
The missing Promise global was the issue... now I'll have to go back and re-try with 2.1.
@stalbert the gain is having 
promise().then().catch()
as opposed to callbacks. Syntactically it's a win b/c of the readability gain.
b
you are probably doomed if you mean plaid-node
c
I did end up stubbing 
setTimeout
. Which worked.
b
those kind of things use the i/o modules that node provides
c
@battk I got most of it working. At some point the extra work wasn't worth it.
If 2.1 has the Promise global, what scheduler does it use?
b
unknown, Promises act a little weird serverside
s
I'd wager there's no 'scheduler' and server side promises just resolve immediately (synchronously).
imho 
promise().then().catch()
is less readable than plain old single thread sequential sync code. 🙂 but if the library forces either that or callback hell then I can't argue promises are better than that. If you're willing to do TypeScript you may even be able to get fancy with 
async
await
Open in Slack
PreviousNext
Powered by