[nodejs] Downside to not wrapping sync callbacks in nextTick()?
I have been writing node.js client code for a couple of years now, and have
authored a couple open source libraries, but somehow I missed the memo
telling me that I'm supposed to wrap 'synchrounous' callbacks in
process.nextTick(). I kind-of understand why that is a best-practice, but
what I don't understand is what the drawback is if you don't do it.
For example, I write code like this all the time, and have never had a
single problem with it:
function getSomething(args, cb) {
if (!args) { return cb(new Error('args required')); }
if (!args.id) { return cb(new Error('args.id required')); }
SomeDatabase.get({id: args.id}, cb);
}
What are the potential issues with not wrapping those arg checks in
process.nextTick()?
Thanks,
Bryan
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Downside to not wrapping sync callbacks in nextTick()?
Thanks Scott.
That's basically what I had gathered from googling around. It seems to me like
it's not necessary to wrap in nextTick for most cases then.
On Aug 20, 2013, at 10:58 AM, Scott González wrote:
> The potential issue is if the person consuming your API expects the callback
> to always be async:
>
> // kick off the async process as early as possible
> doAsync( cb );
> // do some slightly high cost prep work before the callback is invoked
> prepareStateForCallbackWhileWaiting();
>
> Doing the prep work after the async call allows you to reduce the amount of
> time needed between the start of this tick and the tick when the callback is
> actually invoked. Interestingly, the reason some people don't like forcing
> async is for performance gains when the operation can be sync.
>
> You're going to get lots of arguments on both sides.
>
>
>
> On Tue, Aug 20, 2013 at 1:47 PM, Bryan Donovan wrote:
> I have been writing node.js client code for a couple of years now, and have
> authored a couple open source libraries, but somehow I missed the memo
> telling me that I'm supposed to wrap 'synchrounous' callbacks in
> process.nextTick(). I kind-of understand why that is a best-practice, but
> what I don't understand is what the drawback is if you don't do it.
>
> For example, I write code like this all the time, and have never had a single
> problem with it:
>
> function getSomething(args, cb) {
> if (!args) { return cb(new Error('args required')); }
> if (!args.id) { return cb(new Error('args.id required')); }
>
> SomeDatabase.get({id: args.id}, cb);
> }
>
> What are the potential issues with not wrapping those arg checks in
> process.nextTick()?
>
>
> Thanks,
>
> Bryan
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to a topic in the Google
> Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Downside to not wrapping sync callbacks in nextTick()?
Another issue with using process.nextTick() is it ruins the stack trace (which
might be fine or maybe even desirable in some cases, but isn't so great for
error checking/handling). That can be fixed by using bind(), but at that point
we're adding a lot of cruft to the code IMO. (Related gist that shows stack
traces: https://gist.github.com/BryanDonovan/6254656).
As a real-life example, I wrote an Elasticsearch client that checks for missing
args in fashion I mentioned earlier in this thread (e.g.,
https://github.com/BryanDonovan/node-simple-elasticsearch/blob/master/lib/client.js#L94).
Is that something I need to change?
Thanks,
Bryan
On Aug 20, 2013, at 10:47 AM, Bryan Donovan wrote:
> I have been writing node.js client code for a couple of years now, and have
> authored a couple open source libraries, but somehow I missed the memo
> telling me that I'm supposed to wrap 'synchrounous' callbacks in
> process.nextTick(). I kind-of understand why that is a best-practice, but
> what I don't understand is what the drawback is if you don't do it.
>
> For example, I write code like this all the time, and have never had a single
> problem with it:
>
> function getSomething(args, cb) {
> if (!args) { return cb(new Error('args required')); }
> if (!args.id) { return cb(new Error('args.id required')); }
>
> SomeDatabase.get({id: args.id}, cb);
> }
>
> What are the potential issues with not wrapping those arg checks in
> process.nextTick()?
>
>
> Thanks,
>
> Bryan
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to a topic in the Google
> Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Re: Downside to not wrapping sync callbacks in nextTick()?
Thanks for the reply.
However, this is the same answer as what I keep coming across that doesn't
really answer my question. What is the downside? I want to see a real-world
example of what happens when I don't follow this contract. I've yet to see an
example of something bad happening in this situation. I'm sure I'm wrong, but
I need to know *why*.
When would someone ever call:
getSomething(args, cb);
... and then assume they can call something else in the meantime?
Thanks,
Bryan
On Aug 21, 2013, at 12:32 AM, Floby wrote:
> Same as above.
> A "callback" is meant to be called back after some operations are made. In
> node, that means they're probably gonna get called when the current stack has
> unwound. If you called the callback synchronously, that means it behaves
> differently.
> process.nextTick un most cases execute the given function immediately after
> the current stack ends (with some limitations for recursivity) so it's not
> really a performance killer.
>
> Doing so helps you respect your function/method contract :)
>
> Saying that "in most case, it's not needed" is too big of an assumption of
> what your user is doing with your code. IMO.
>
>
> On Tuesday, 20 August 2013 19:47:22 UTC+2, Bryan Donovan wrote:
> I have been writing node.js client code for a couple of years now, and have
> authored a couple open source libraries, but somehow I missed the memo
> telling me that I'm supposed to wrap 'synchrounous' callbacks in
> process.nextTick(). I kind-of understand why that is a best-practice, but
> what I don't understand is what the drawback is if you don't do it.
>
> For example, I write code like this all the time, and have never had a single
> problem with it:
>
> function getSomething(args, cb) {
> if (!args) { return cb(new Error('args required')); }
> if (!args.id) { return cb(new Error('args.id required')); }
>
> SomeDatabase.get({id: args.id}, cb);
> }
>
> What are the potential issues with not wrapping those arg checks in
> process.nextTick()?
>
>
> Thanks,
>
> Bryan
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to a topic in the Google
> Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Re: Downside to not wrapping sync callbacks in nextTick()?
Thanks Scott, that thread was very helpful.
I think I get it now, but it does seem to me that executing the callback
synchronously in the particular ways I've been doing it is ok. If I were
following a convention like:
function connect(cb) {
process.nextTick(cb);
return {
foo: function() {
console.log('foo!');
}
};
}
function foo() {
var client = connect(function() {
client.foo();
});
}
foo();
.. then I totally see why we need to use nextTick there.
But I guess I'll change my public libraries to use nextTick() just in case
someone uses them in a strange way.
Thanks again,
Bryan
On Aug 21, 2013, at 5:33 AM, Scott González wrote:
> https://groups.google.com/d/msg/nodejs/FNsM6Ns1MkE/4Ys-l1RI0Q0J
>
>
> On Wed, Aug 21, 2013 at 4:19 AM, Bryan Donovan wrote:
> Thanks for the reply.
>
> However, this is the same answer as what I keep coming across that doesn't
> really answer my question. What is the downside? I want to see a real-world
> example of what happens when I don't follow this contract. I've yet to see an
> example of something bad happening in this situation. I'm sure I'm wrong,
> but I need to know *why*.
>
> When would someone ever call:
>
>getSomething(args, cb);
>
> ... and then assume they can call something else in the meantime?
>
>
> Thanks,
>
> Bryan
>
>
> On Aug 21, 2013, at 12:32 AM, Floby wrote:
>
>> Same as above.
>> A "callback" is meant to be called back after some operations are made. In
>> node, that means they're probably gonna get called when the current stack
>> has unwound. If you called the callback synchronously, that means it behaves
>> differently.
>> process.nextTick un most cases execute the given function immediately after
>> the current stack ends (with some limitations for recursivity) so it's not
>> really a performance killer.
>>
>> Doing so helps you respect your function/method contract :)
>>
>> Saying that "in most case, it's not needed" is too big of an assumption of
>> what your user is doing with your code. IMO.
>>
>>
>> On Tuesday, 20 August 2013 19:47:22 UTC+2, Bryan Donovan wrote:
>> I have been writing node.js client code for a couple of years now, and have
>> authored a couple open source libraries, but somehow I missed the memo
>> telling me that I'm supposed to wrap 'synchrounous' callbacks in
>> process.nextTick(). I kind-of understand why that is a best-practice, but
>> what I don't understand is what the drawback is if you don't do it.
>>
>> For example, I write code like this all the time, and have never had a
>> single problem with it:
>>
>> function getSomething(args, cb) {
>> if (!args) { return cb(new Error('args required')); }
>> if (!args.id) { return cb(new Error('args.id required')); }
>>
>> SomeDatabase.get({id: args.id}, cb);
>> }
>>
>> What are the potential issues with not wrapping those arg checks in
>> process.nextTick()?
>>
>>
>> Thanks,
>>
>> Bryan
>>
>> --
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "nodejs" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> nodejs+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this gro
Re: [nodejs] Re: Downside to not wrapping sync callbacks in nextTick()?
Cool. I've updated node-simple-elasticsearch to call back with errors
asynchronously:
https://github.com/BryanDonovan/node-simple-elasticsearch/blob/master/lib/validator.js
(at least I think I did it right).
Bryan
On Aug 22, 2013, at 9:49 AM, Scott González wrote:
> This is just the robustness principle/Postel's law: Be conservative in what
> you send, be liberal in what you accept.
>
> If you're implementing an API, you should be consistent. If you're consuming
> the API, you should be defensive. But honestly, people writing node modules
> should follow the node patterns and never mix sync and async behavior.
>
>
> On Thu, Aug 22, 2013 at 12:44 PM, Eldar wrote:
> I always followed the simple rule "callback may be called at any time" and I
> was pretty happy so far.
> The resulting code is more portable and simpler. Just use tail recursive
> algorithms and be happy.
>
> вторник, 20 августа 2013 г., 21:47:22 UTC+4 пользователь Bryan Donovan
> написал:
> I have been writing node.js client code for a couple of years now, and have
> authored a couple open source libraries, but somehow I missed the memo
> telling me that I'm supposed to wrap 'synchrounous' callbacks in
> process.nextTick(). I kind-of understand why that is a best-practice, but
> what I don't understand is what the drawback is if you don't do it.
>
> For example, I write code like this all the time, and have never had a single
> problem with it:
>
> function getSomething(args, cb) {
> if (!args) { return cb(new Error('args required')); }
> if (!args.id) { return cb(new Error('args.id required')); }
>
> SomeDatabase.get({id: args.id}, cb);
> }
>
> What are the potential issues with not wrapping those arg checks in
> process.nextTick()?
>
>
> Thanks,
>
> Bryan
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to a topic in the Google
> Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Re: Downside to not wrapping sync callbacks in nextTick()?
Because the calling code calls back with the error (e.g.,
https://github.com/BryanDonovan/node-simple-elasticsearch/blob/master/lib/client.js#L54),
and it was easier to add the nextTick() stuff inside the validator function
instead of in each caller. I previously had it purely synchronous.. but
changed it because of this thread. That validator.js file is not exported in
the npm.. it's private.
Here's the diff to the previous version:
https://github.com/BryanDonovan/node-simple-elasticsearch/commit/2dc50f2b59c69ef070df26714a3456831feda618
-Bryan
On Aug 22, 2013, at 11:22 AM, Scott González wrote:
> The success case is synchronous. It looks like there's nothing that ever
> needs to be async in that function. Why does this take a callback instead of
> just returning a boolean?
>
>
> On Thu, Aug 22, 2013 at 2:08 PM, Bryan Donovan wrote:
> Cool. I've updated node-simple-elasticsearch to call back with errors
> asynchronously:
> https://github.com/BryanDonovan/node-simple-elasticsearch/blob/master/lib/validator.js
>
> (at least I think I did it right).
>
> Bryan
>
>
> On Aug 22, 2013, at 9:49 AM, Scott González wrote:
>
>> This is just the robustness principle/Postel's law: Be conservative in what
>> you send, be liberal in what you accept.
>>
>> If you're implementing an API, you should be consistent. If you're consuming
>> the API, you should be defensive. But honestly, people writing node modules
>> should follow the node patterns and never mix sync and async behavior.
>>
>>
>> On Thu, Aug 22, 2013 at 12:44 PM, Eldar wrote:
>> I always followed the simple rule "callback may be called at any time" and I
>> was pretty happy so far.
>> The resulting code is more portable and simpler. Just use tail recursive
>> algorithms and be happy.
>>
>> вторник, 20 августа 2013 г., 21:47:22 UTC+4 пользователь Bryan Donovan
>> написал:
>> I have been writing node.js client code for a couple of years now, and have
>> authored a couple open source libraries, but somehow I missed the memo
>> telling me that I'm supposed to wrap 'synchrounous' callbacks in
>> process.nextTick(). I kind-of understand why that is a best-practice, but
>> what I don't understand is what the drawback is if you don't do it.
>>
>> For example, I write code like this all the time, and have never had a
>> single problem with it:
>>
>> function getSomething(args, cb) {
>> if (!args) { return cb(new Error('args required')); }
>> if (!args.id) { return cb(new Error('args.id required')); }
>>
>> SomeDatabase.get({id: args.id}, cb);
>> }
>>
>> What are the potential issues with not wrapping those arg checks in
>> process.nextTick()?
>>
>>
>> Thanks,
>>
>> Bryan
>>
>> --
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "nodejs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nodejs+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>> --
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "nodejs" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> nodej
Re: [nodejs] Re: Downside to not wrapping sync callbacks in nextTick()?
Yeah, I agree. I originally did it this way because I erroneously thought I'd
have to do some kind of cb.bind() trickery to preserve stack traces, and that
was too much cruft in the main client code.
On Aug 22, 2013, at 11:36 AM, Scott González wrote:
> To be honest, it seems like laziness over correctness. You now can't have a
> method that just validates synchronously. You also now need to trace the code
> to prove the correctness of the code, since you need to ensure that any use
> of the validation will result in an async callback at some point. Or you can
> put the success case inside a nextTick() as well, but then you're taking an
> unnecessary hit everywhere, not just on error.
>
>
> On Thu, Aug 22, 2013 at 2:30 PM, Bryan Donovan wrote:
> Because the calling code calls back with the error (e.g.,
> https://github.com/BryanDonovan/node-simple-elasticsearch/blob/master/lib/client.js#L54),
> and it was easier to add the nextTick() stuff inside the validator function
> instead of in each caller. I previously had it purely synchronous.. but
> changed it because of this thread. That validator.js file is not exported in
> the npm.. it's private.
>
> Here's the diff to the previous version:
> https://github.com/BryanDonovan/node-simple-elasticsearch/commit/2dc50f2b59c69ef070df26714a3456831feda618
>
> -Bryan
>
>
> On Aug 22, 2013, at 11:22 AM, Scott González wrote:
>
>> The success case is synchronous. It looks like there's nothing that ever
>> needs to be async in that function. Why does this take a callback instead of
>> just returning a boolean?
>>
>>
>> On Thu, Aug 22, 2013 at 2:08 PM, Bryan Donovan wrote:
>> Cool. I've updated node-simple-elasticsearch to call back with errors
>> asynchronously:
>> https://github.com/BryanDonovan/node-simple-elasticsearch/blob/master/lib/validator.js
>>
>> (at least I think I did it right).
>>
>> Bryan
>>
>>
>> On Aug 22, 2013, at 9:49 AM, Scott González wrote:
>>
>>> This is just the robustness principle/Postel's law: Be conservative in what
>>> you send, be liberal in what you accept.
>>>
>>> If you're implementing an API, you should be consistent. If you're
>>> consuming the API, you should be defensive. But honestly, people writing
>>> node modules should follow the node patterns and never mix sync and async
>>> behavior.
>>>
>>>
>>> On Thu, Aug 22, 2013 at 12:44 PM, Eldar wrote:
>>> I always followed the simple rule "callback may be called at any time" and
>>> I was pretty happy so far.
>>> The resulting code is more portable and simpler. Just use tail recursive
>>> algorithms and be happy.
>>>
>>> вторник, 20 августа 2013 г., 21:47:22 UTC+4 пользователь Bryan Donovan
>>> написал:
>>> I have been writing node.js client code for a couple of years now, and have
>>> authored a couple open source libraries, but somehow I missed the memo
>>> telling me that I'm supposed to wrap 'synchrounous' callbacks in
>>> process.nextTick(). I kind-of understand why that is a best-practice, but
>>> what I don't understand is what the drawback is if you don't do it.
>>>
>>> For example, I write code like this all the time, and have never had a
>>> single problem with it:
>>>
>>> function getSomething(args, cb) {
>>> if (!args) { return cb(new Error('args required')); }
>>> if (!args.id) { return cb(new Error('args.id required')); }
>>>
>>> SomeDatabase.get({id: args.id}, cb);
>>> }
>>>
>>> What are the potential issues with not wrapping those arg checks in
>>> process.nextTick()?
>>>
>>>
>>> Thanks,
>>>
>>> Bryan
>>>
>>> --
>>> --
>>> Job Board: http://jobs.nodejs.org/
>>> Posting guidelines:
>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>> You received this message because you are subscribed to the Google
>>> Groups "nodejs" group.
>>> To post to this group, send email to nodejs@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> nodejs+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>>
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "nod
Re: [nodejs] Re: Downside to not wrapping sync callbacks in nextTick()?
The stack trace is only ruined if the error is created inside the nextTick()
block. See:
https://gist.github.com/BryanDonovan/6254656
On Aug 23, 2013, at 7:53 AM, Chaoran Yang wrote:
> I think using nextTick() for error handling is a very very bad idea.
>
> Stack trace could be very helpful when error happens. use nextTick basically
> throws that stack trace ability away.
>
> Moreover, the whole nextTick thing is stupid IMO. When I use an asynchronous
> API, I always assume it *may* be optimized for some cases to run
> synchronously. So changing the state of a callback function between it is
> used and it is called is a very very bad idea. In almost every case I ran
> into, it turned out to be a programmer mistake rather than an intended
> behavior. The programmer should *NOT* assume a guaranteed execution order. It
> is a very unnecessary overhead (sometimes also very large) to pay for API
> developers just to guarantee execution order, because execution order is
> irrelevant in most cases.
>
> To sum up,
> 1) Programmer should assume an asynchronous API may callback synchronously
> because of optimization for some fast path.
> 2) Guarantee execution order of a callback is unnecessary in most cases, so
> it's an overhead that should be avoided by default.
> 3) Definitely DO NOT use nextTick for error handling code, because it throws
> away the stack information for nothing.
>
> -Chaoran
>
> On Tuesday, August 20, 2013 12:47:22 PM UTC-5, Bryan Donovan wrote:
> I have been writing node.js client code for a couple of years now, and have
> authored a couple open source libraries, but somehow I missed the memo
> telling me that I'm supposed to wrap 'synchrounous' callbacks in
> process.nextTick(). I kind-of understand why that is a best-practice, but
> what I don't understand is what the drawback is if you don't do it.
>
> For example, I write code like this all the time, and have never had a single
> problem with it:
>
> function getSomething(args, cb) {
> if (!args) { return cb(new Error('args required')); }
> if (!args.id) { return cb(new Error('args.id required')); }
>
> SomeDatabase.get({id: args.id}, cb);
> }
>
> What are the potential issues with not wrapping those arg checks in
> process.nextTick()?
>
>
> Thanks,
>
> Bryan
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to a topic in the Google
> Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Downside to not wrapping sync callbacks in nextTick()?
This is certainly only way I've ever programmed in node.js. I really don't like
APIs like this:
var client = connect(function() {
client.do_something(function() {
//..
});
});
… they're just weird. This makes a lot more sense to me:
connect(function(err, client) {
client.do_something(function() {
//..
});
});
I know the first way might be necessary in some cases, but I avoid it if
possible.
On Aug 23, 2013, at 8:59 AM, Chaoran Yang wrote:
> I think the best way to go would be educating programmers to assume all
> asynchronous calls may be executed synchronously
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Downside to not wrapping sync callbacks in nextTick()?
Thanks for the post, Isaac. Very helpful.
I totally understand the logic of being consistent -- I'm known to be ruthless
about consistency at work. I'm changing my public node.js libraries to use
nextTick() instead of calling back immediately.
However, I'm still unsure of when someone would ever care if I called back
immediately in my examples, where I'm just checking for the correct args. An
example use case:
var db = {
get: function(args, cb) {
args = args || {};
if (!args.index) { return cb(new Error('index required')); }
if (!args.type) { return cb(new Error('type required')); }
doSomethingAsync(args, cb);
}
};
function getSomething(args, cb) {
db.get(args, cb);
}
// Express.js-style route
app.get('/foo', function(req, res) {
var args = {index: req.params.index, type: req.params.type, id:
req.params.id};
getSomething(args, function(err, result) {
if (err) {
res.send(500, JSON.stringify(err));
} else {
res.send(200, JSON.stringify(result));
}
});
});
This is how I'd expect people to use this client. I must still be missing
something, but *in this situation* I still don't see where someone would run
into trouble due to the error callbacks being returned immediately.
Thanks,
Bryan
On Aug 28, 2013, at 6:16 PM, Isaac Schlueter wrote:
> Bryan,
>
> I wrote this for you.
> http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony
>
> On Fri, Aug 23, 2013 at 10:58 AM, Scott González
> wrote:
>> On Fri, Aug 23, 2013 at 1:46 PM, Chaoran Yang
>> wrote:
I have never seen such cases ... and can't imagine them ... but
potentially yes ...
>>>
>>>
>>> The cursor.nextObject() of node-mongodb-native that @Eldar has brought up
>>> is a pretty good one.
>>
>>
>> Are there real world benchmarks showing that this is a legitimate
>> performance bottleneck?
>>
>> --
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "nodejs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nodejs+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to a topic in the Google
> Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Downside to not wrapping sync callbacks in nextTick()?
That's not the same situation though. What bad can happen in my most recent example? On Aug 29, 2013, at 9:57 AM, Scott González wrote: > On Thu, Aug 29, 2013 at 12:51 PM, Bryan Donovan wrote: > However, I'm still unsure of when someone would ever care if I called back > immediately in my examples, where I'm just checking for the correct args. > > Oleg's generic example seemed pretty clear to me: > https://groups.google.com/d/msg/nodejs/0TmVfX9z1R0/y46iAwFEJ0YJ > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to a topic in the Google > Groups "nodejs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > nodejs+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Downside to not wrapping sync callbacks in nextTick()?
Thanks, I just wanted to make sure my understanding was correct in that there really is no problem with the specific case I presented. On Aug 29, 2013, at 11:16 AM, Scott González wrote: > Yes, it's possible to construct specific situations that don't have problems. > Nobody is denying that. But it's irrelevant if it's also possible to > construct situations that do have problems. > > > On Thu, Aug 29, 2013 at 1:50 PM, Bryan Donovan wrote: > That's not the same situation though. What bad can happen in my most recent > example? > > On Aug 29, 2013, at 9:57 AM, Scott González wrote: > >> On Thu, Aug 29, 2013 at 12:51 PM, Bryan Donovan wrote: >> However, I'm still unsure of when someone would ever care if I called back >> immediately in my examples, where I'm just checking for the correct args. >> >> Oleg's generic example seemed pretty clear to me: >> https://groups.google.com/d/msg/nodejs/0TmVfX9z1R0/y46iAwFEJ0YJ >> >> -- >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to nodejs@googlegroups.com >> To unsubscribe from this group, send email to >> nodejs+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "nodejs" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> nodejs+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to nodejs+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to a topic in the Google > Groups "nodejs" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > nodejs+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Downside to not wrapping sync callbacks in nextTick()?
On Aug 29, 2013, at 7:09 PM, Isaac Schlueter wrote:
> On Thu, Aug 29, 2013 at 11:19 AM, Bryan Donovan wrote:
>> Thanks, I just wanted to make sure my understanding was correct in that
>> there really is no problem with the specific case I presented.
>
> That understanding is incorrect.
>
> The exact problem being described in Havoc's post and in mine, is a
> problem with the specific case you presented.
I do understand how it's inconsistent, and I see how it *could* be a problem,
but I still haven't seen an example of how my example would cause a real
problem in a real application. Let's pretend it's not a public npm for a
minute and this 'db' is a home-grown internal module. Say I'm on a team with
10 developers, all working on a REST API using this module. Is there a
scenario that would cause a problem in this app due to immediately calling back?
I'm trying to figure out whether it's worth it to go back and change every
place in our app that does an immediate callback.
Given that I haven't seen any issues with this in two years, I doubt it's
really an issue (again, for an internal app, not a public library). But maybe
there are issues we just haven't noticed.
>
> Throw now, or nextTick the callback. Don't do it half-way.
>
> On Thu, Aug 29, 2013 at 7:04 PM, Isaac Schlueter wrote:
>>if (!args.index) { next(new Error('index required')); }
>>if (!args.type) { next(new Error('type required')); }
>
> Ugh, a bug in my example. It should be `return next(new Error(...))`,
> so that it doesn't try to do the async thing if it's already called
> the cb with an error.
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to a topic in the Google
> Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Downside to not wrapping sync callbacks in nextTick()?
Yeah, I really dislike this "pattern". It's confusing at best. I never
understood the reason for designing an API this way. I suspect it has
something to do with emitting events, like in the http module.
On Aug 30, 2013, at 9:48 AM, Paul wrote:
> That means never doing something that seems dirty like this:
>
> var thing = doThing(function() {
> thing.doSomething(); // wtf? why should I have to reason about whether
> this is valid here or not, just assume it is NOT
> });
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [nodejs] Downside to not wrapping sync callbacks in nextTick()?
Right, I get that.
On Sep 1, 2013, at 8:59 AM, dhruvbird wrote:
> @Bryan: Be careful when using the EventEmitter like pattern because:
>
> var e = new ObjectDerivingFromEventEmitter()
> e.makeRequest(request_parameters);
> e.on('error', function() { });
>
> Now, if makeRequest() were to emit the 'error' event synchronously, the
> client code will not be able to catch it.
>
> Even worse is when e.makeRequest() returns a response object and the error is
> emitted on that response object. There is no way to catch this 'error' event
> but to raise it in nextTick().
>
>
>
> On Tuesday, August 20, 2013 11:12:35 AM UTC-7, Bryan Donovan wrote:
> Thanks Scott.
>
> That's basically what I had gathered from googling around. It seems to me
> like it's not necessary to wrap in nextTick for most cases then.
>
>
> On Aug 20, 2013, at 10:58 AM, Scott González wrote:
>
>> The potential issue is if the person consuming your API expects the callback
>> to always be async:
>>
>> // kick off the async process as early as possible
>> doAsync( cb );
>> // do some slightly high cost prep work before the callback is invoked
>> prepareStateForCallbackWhileWaiting();
>>
>> Doing the prep work after the async call allows you to reduce the amount of
>> time needed between the start of this tick and the tick when the callback is
>> actually invoked. Interestingly, the reason some people don't like forcing
>> async is for performance gains when the operation can be sync.
>>
>> You're going to get lots of arguments on both sides.
>>
>>
>>
>> On Tue, Aug 20, 2013 at 1:47 PM, Bryan Donovan wrote:
>> I have been writing node.js client code for a couple of years now, and have
>> authored a couple open source libraries, but somehow I missed the memo
>> telling me that I'm supposed to wrap 'synchrounous' callbacks in
>> process.nextTick(). I kind-of understand why that is a best-practice, but
>> what I don't understand is what the drawback is if you don't do it.
>>
>> For example, I write code like this all the time, and have never had a
>> single problem with it:
>>
>> function getSomething(args, cb) {
>> if (!args) { return cb(new Error('args required')); }
>> if (!args.id) { return cb(new Error('args.id required')); }
>>
>> SomeDatabase.get({id: args.id}, cb);
>> }
>>
>> What are the potential issues with not wrapping those arg checks in
>> process.nextTick()?
>>
>>
>> Thanks,
>>
>> Bryan
>>
>> --
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nod...@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+un...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "nodejs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nodejs+un...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>> --
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nod...@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+un...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "nodejs" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/nodejs/0TmVfX9z1R0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> nodejs+un...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Ma
Re: [nodejs] Re: Modest proposal to make async optional in Node.js
The Ace lib does this, via some Fiber stuff. https://github.com/maccman/ace. I've never tried it myself though. BTW, with ruby 1.9 you can handle lots of requests per process via native Fiber support. See Sinatra::Synchrony (https://github.com/kyledrake/sinatra-synchrony) and Goliath (http://www.igvita.com/2011/03/08/goliath-non-blocking-ruby-19-web-server/). They both work very well, with pure synchronous code style. Bryan On Apr 1, 2012, at 7:49 PM, Olivier Lalonde wrote: > > Many times I invoke something without a callback. > > I didn't think about this. It seems this problem would only affect "output" > functions. Not convinced it is a deal breaker yet, I'll try to come up with > some workarounds. > > > You know that you couldn't do anything async like serve web pages, right? > > I'm aware of that. Writing sync web apps would imply using one process/worker > by request like other popular languages do (PHP/Ruby/etc.). I think it is > still interesting to use Javascript for backend development even without the > async stuff. > > On Monday, April 2, 2012 10:20:01 AM UTC+8, Olivier Lalonde wrote: > I'm sorry if this has been discussed before, but I couldn't find anything. > This a modest proposal to introduce sync APIs in Node.js > > A lot of people would like to use Javascript for their web backend, but don't > want to program in an async style (I believe those reasons have already been > discussed at length). > > As it stands right now, it is practically impossible to program in Node.js in > a sync style, since most core modules and native extensions only provide an > async interface. > > I believe there would be an easy way to change the status quo without > impacting developers who chose to adhere to a strict async style. The > solution I propose is simply a pattern for writing I/O APIs: every I/O call > should be async unless no call back is supplied, in which case the I/O call > should be sync and use return / throw statements instead of calling a > callback. > > There is probably a flaw in my reasoning since I'm probably not the first one > to come up with this pattern. That being said, I think it would be an elegant > way to make both async/sync fans happy while keeping all the backend JS > community focused on one project rather than fragmenting the community in > multiple CommonJS server implementations. > > Thoughts? > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
Re: [nodejs] Re: How to avoid callback hell?
The EasyMySQL npm eliminates these callbacks and uses a connection pool, so it
only opens a new connection when needed.
Sent from an iPhone.
On Apr 8, 2012, at 6:17 PM, Matthew Hazlett wrote:
> Thats how I originally did it, but when you need to do multiple queries to
> the database you shoud open the connection once and reuse it instead of
> opening it multiple times a session.
>
>
> On 4/8/2012 9:14 PM, Matt Patenaude wrote:
>>
>> I agree, it seems entirely manageable.
>>
>> One low-overhead option would be just to split that out into a function, if
>> it's used frequently:
>>
>> function dbQuery(query, callback){
>>db.open(... fn() {
>>db.collection( fn() {
>> db.query(query, callback);
>> });
>> });
>> }
>>
>>
>> dbQuery("SELET * FROM blah", fn() {
>> // stuff you would have done in the inner-most part here
>> });
>>
>>
>> -Matt
>>
>> On Apr 8, 2012, at 9:06 PM, Mark Hahn wrote:
>>
>>> > But as you can see this creates callback hell.
>>>
>>> It doesn't look that bad to me.
>>>
>>>
>>> --
>>> Job Board: http://jobs.nodejs.org/
>>> Posting guidelines:
>>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>>> You received this message because you are subscribed to the Google
>>> Groups "nodejs" group.
>>> To post to this group, send email to nodejs@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> nodejs+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
Re: [nodejs] Any way to do benchmark of http handlers for request and response without send request?
Seems like you could use http://benchmarkjs.com/ and pass in mock/fake objects to the handler functions. Sent from an iPhone. On Apr 22, 2012, at 9:41 AM, jason.桂林 wrote: > I am writing a project named 'kickstart' aim to create high performance web > APP template (not view template). > > I hope the speed could close to node helloworld app. > > So I need some way to benchmark my app. I use ab, but it has big problem in > Mac OS. > > So, I hope, there is a tool could pass fake request and response to my > handlers, do all benchmark without network. > > Can I ? > > BTW, I have done very fast request dispatch. > > https://github.com/guileen/node-kickstart > > -- > Best regards, > > Jason Green > 桂林 > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
Re: [nodejs] Any way to do benchmark of http handlers for request and response without send request?
P.s., if you write unit tests for this same code, I think the answer will emerge on its own :). I personally like mocha for tests. Sent from an iPhone. On Apr 22, 2012, at 9:41 AM, jason.桂林 wrote: > I am writing a project named 'kickstart' aim to create high performance web > APP template (not view template). > > I hope the speed could close to node helloworld app. > > So I need some way to benchmark my app. I use ab, but it has big problem in > Mac OS. > > So, I hope, there is a tool could pass fake request and response to my > handlers, do all benchmark without network. > > Can I ? > > BTW, I have done very fast request dispatch. > > https://github.com/guileen/node-kickstart > > -- > Best regards, > > Jason Green > 桂林 > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to nodejs@googlegroups.com > To unsubscribe from this group, send email to > nodejs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
Re: [nodejs] Async testing with nodeunit
What does svr.login() look like?
On May 17, 2012, at 4:50 AM, Osher El-Netanany wrote:
> Hi all
>
> I'm trying to use nodeunit for asynchronous testing,
>
> my code is like:
> var svr = require("mysvr")
> ;
> svr.listen(5353);
> module.exports =
> { login:
> function(is) {
>svr.login( { usr: "u", pwd: "p" }
>, function(err, res){
> is.ok(!err);
> is.done();
> }
>);
> }
> }
>
> my test runner is like:
>
> var reporter = require('nodeunit').reporters.verbose
> ;
>
> //TODO - get list of files from conventional folder structure
> // or traverse folder tree for name convention...
> reporter.run(
> ['ua.js'
> // ,'test2.js'
> ]
> );
>
> However, running it throws an error of undone tests:
>
> D:\ws\OSGE\1000\sources\auth>node run_tests.js
>
> ua.js
>
> FAILURES: Undone tests (or their setups/teardowns):
> - login
>
> To fix this, make sure all tests call test.done()
>
>
> Now, the server works. No doubt about it.
> I'm trying to automate the tests.
> I fiddled a little with expresso, but I would feel better with nodeunit, if
> we could get it work...
>
> Help anyone?
>
> Osher
>
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
[nodejs] Re: Cycle require()
I might be missing the purpose of your factory, but maybe you can just
implement it like this:
function PluginFactory() {
//
}
exports.PluginFactory = new PluginFactory();
As long as you don't mess with the require cache, I think that would
effectively be a singleton. Maybe there are other reasons to implement the
singleton like you did though.
-Bryan
On Tuesday, March 25, 2014 6:50:27 AM UTC-6, scrf...@avans.nl wrote:
>
> Hi,
>
> So i'm having problems with my architecture of my node application, I know
> the problem, I'm just trying to find the best solution.
>
> My problems is exactly the same as:
> https://groups.google.com/forum/#!topic/nodejs/u_9IE2z_6rM
>
> Only I'm using a Factory class to create plugins of the type "IPlugin".
> These plugins have certain actions, called PluginAction.
>
> A PluginAction has a field plugin, which refers to its parent plugin. When
> serializing to JSON, i replace the plugin object with a string identifier,
> pointing to the correct plugin.
>
> My PluginFactory can retrieve a plugin using retrieve(identifier). The
> problem occurs when I try to deserialize a given PluginAction.
>
> At that point I would like to convert the plugin identifier back to the
> plugin object, by retrieving it from the Factory. This is where it goes
> wrong.
>
> I understand this could be a bit hard to follow, so I've included a part
> of my class diagram, which might clarify it more. Short summary:
>
>
>1. PluginFactory.initialize() loads all plugins in a certain directory
>using require()
>2. PluginAction.toJSON() changes the plugin object to a string
>containing the plugin identifier
>3. PluginAction.fromJSON() when trying to retrieve the plugin object
>using the PluginFactory, I cannot load the PluginFactory file.
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[nodejs] Re: Cannot comprehend module-based inheritance and composition
Your example works for me.
On Sunday, March 1, 2015 at 8:15:09 PM UTC-8, Aaron Martone wrote:
>
> Sorry in advance, I've been at this problem for 6 days now and have failed
> at every single turn on what I need to do. I simply cannot afford to waste
> more time, so I'm asking for help.
>
> My directory structure looks like this:
>
> /root
> /controllers
> server.ctrl.js
> /libs
> /classes
> Server.js
> ServerController.js
> server.app.js
>
> I am trying to create a "Server" class based on /libs/classes/Server.js.
> When instantiated, it takes 1 param, the constant ENV (environment), which
> is stored in its THIS scope.
> One of the properties of the "Server" object is called 'ctrl' and that
> should be set to an instance of the 'ServerController' class at
> /libs/classes/ServerController.js
>
> The 'ServerController' needs to inherit via the prototype chain, the
> properties on the 'Server' so that it can gain access to the 'THIS' scope's
> 'ENV' when it references 'this.ENV'.
> I have tried everything I can think of, many times 20x over, and cannot
> figure out how this is done. Hopefully I have explained my situation well
> enough. I'm able to do inheritance without modules, but something about
> Node's module exporting is throwing me off my understanding.
>
> *FYI*. The ServerController 'class' requires the /controllers/server.ctrl
> module which exports an object of functions that the ServerController class
> returns as direct functions off itself. Since ServerController gets stored
> in the Server object's 'ctrl' property, I was hoping I could call it via
> Server.ctrl.functionName();
>
>
> *==*
> *FROM HERE BELOW ARE THINGS I'VE TRIED, NOT NECESSARY TO THE QUESTION*
> *==*
>
>
>
> *in server.app.js:*
> var Server = require('./libs/classes/Server'); // the 'Server' class.
> var ServerController = require('./libs/classes/ServerController'); // the
> 'ServerController' class.
>
> var ctrl = new ServerController();
> var server = new Server(ENV, ctrl);
>
> *in Server.js*:
> function Server(ENV, ctrl) { this.ENV = ENV; this.ctrl = ctrl; }
> Server.prototype.test = function() { console.log('Server-level test'); }
> module.exports = Server;
>
> *in ServerController.js:*
> var Server = require('./Server');
> function ServerController() { }
> ServerController.prototype = Object.create(Server.prototype);
> ServerController.prototype.test = function() {
> console.log('Controller-level test, shadows Server-level'); }
> module.exports = ServerController;
>
> *Then I try to run things like:*
> server.test(); // Expecting 'Server-level test'
> server.ctrl.test(); // Expecting 'Controller-level test, shadows
> Server-level');
>
> But I'm running into tons of errors.
>
--
Job board: http://jobs.nodejs.org/
New group rules:
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
To post to this group, send email to nodejs@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/nodejs/4926d6ba-ac56-49d5-80a9-44d0c5b98d4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
