3

After reading several posts about event driven and nodejs, the only advantages I can see are that event driven avoids the memory allocation for threads and replaces polling with notifications where possible.

The other advantages are all arguable:

  1. Multithread program is easier to make mistakes than single thread.

    Argue: for web applications, requests are independent from each other, as long as the handler functions has no side effect; if all the IO parts are handled by database servers, there is nothing to worry about multithreading.

  2. The event driven approach will not block on IO, and thus could handle more requests. This advantage seems the most important feature of event driven. And in this example it is compared to the doctor offices, which I think is not proper.

    Argue: In the doctor offices example, receptionist do not wait for a patient to fill in the forms, but serves the other patients while the previous patient is filling the form. This is a misleading example.

    a. If we interprete patients as clients sending request to the server. The server of course will not block for the clients to fill in the forms in their own browser. And when the clients finish the forms and send a http POST to the server, then the server will start working. The web has already been an event driven system before nodejs exists. So this example is not valid to explain server side event driven programming.

    b. Someone would say that we should interprete the patient filling the forms as the server side IO intensive operations. But the difference is: we don't pay for the patients to fill in the forms, but we pay for IO intensive operations.

    So my argue is that, even the time consuming operations are not blocking your current thread, there's gonna be some other thread, or process or database server blocked. I see many times that nodejs can serve 10k concurrent connections because it is none blocking. I would say that, if there are not enough other threads or processes or servers to handle the time consuming part, it would not be possible.

In this case, event driven is nothing more than load balancing using nginx, except that load balancing balances the request to applications, while the event driven balances the request to time consuming operations, which moves the load balancing layer backwards. And the only advantage of doing so are the two I mentioned in the beginning of this question: 1. it avoids the memory allocation for threads. 2. replaces polling with notifications where possible.

Thank you for reading to this point, my question is: is my understanding correct? Any mistakes I made in my argument?

Min Lin
  • 3,177
  • 2
  • 19
  • 32
  • 2
    When it comes down to it you still have to write code that handles `"events"`. What you seem to be getting caught up on is the style when you should focus more on substance. `"Is my code maintainable, performant, reliable?"` – ChaosPandion Mar 23 '13 at 06:35
  • 1
    Check the answer to this question as I think it may enhance your understanding: http://stackoverflow.com/questions/3629784/how-is-node-js-inherently-faster-when-it-still-relies-on-threads-internally – phairoh Mar 23 '13 at 07:55
  • @Phairoh Thanks for the information. So I think basically I'm understanding it right. By doing async and callbacks, the task scheduling is more efficient, because of less polling more notification. – Min Lin Mar 23 '13 at 08:07

1 Answers1

4

As ChaosPandion said in a comment, it seems like you are getting caught up in style. Event based programming is just another way to manage data flow through your program with different tradeoffs. For some applications it makes things very easy, for others (CPU driven problems, for example) it's not particularly good.

Many applications don't have any significantly time consuming operations. In your example of accessing a database, that's just the application waiting for a response (the event).

Being event based can also save a lot of programming work managing communication between threads.

For another perspective, see "concurrency is not parallelism" and the concurrency section in Effective Go.

Ask Bjørn Hansen
  • 6,784
  • 2
  • 26
  • 40
  • "For some applications it makes things very easy, for others (CPU driven problems, for example) it's not particularly good." – isn't queuing up events for CPU-intensive tasks considered as a conventional way of unloading work? Given that tasks are gonna be consumed by multiple (scalable) workers/processes? – Taras Mykhalchuk May 17 '23 at 15:30