Node.js as a server-side for an enterprise application?

Question

JavaScript

Task:
Develop a web application with cunning business logic and the ability to use one code for calculations both on the client and on the server.
Java is not considered because:
1. there is already a web version of this application and there are users who are used to using this application through a browser without installing any additional software, including from tablets;
2. there is a team of web developers, there is no team of Java developers.
The server part initially works in PHP, but during the development of the application, a significant drawback of the approach with different languages ​​on the client and server was revealed: in order for the application to be more responsive, sometimes it is necessary to perform the same calculations both on the server and on the client, and therefore it is necessary to support twice as much code, which leads to various bugs and inaccuracies.
Question:
Please tell us about your experience of using node.js as a server for applications with complex business logic. What technologies/frameworks did you use, what pitfalls did you encounter?
Thanks in advance.
Similar, but different in essence, question: habrahabr.ru/qa/45892/

Answer 1

In my experience, nodejs is comfortable, stable, and fast, with a great community and a lot of good libraries on npm. The benefits can be listed for a long time, it is better to go straight to the problems.
— It is difficult to find intelligent programmers ready for work, even among front-end developers. But you can teach. It takes about a month or two to learn and understand the nodejs environment, API, asynchrony, closures, callbacks, events, a functional approach.
- Libraries from the frontends can be used, but only if they are well-written and optimized for permanent work. Otherwise, there is a risk that they will gobble up all the memory or hang themselves.
- The nodejs server is usually single-threaded, with all the consequences. It is possible to fork and open child processes, this requires additional labor costs. But this is required only in exceptional cases.
- The code is written mostly easily if you follow a clear standard, which is usually imposed by the framework used. However, javascript, due to its laxity, is not resistant to corrosion, in a hurry or due to inexperience, you can do cancer and turn the life of your team into hell.
- With complex logic with many calls, you can pile up “ladders” of calbacks without malicious intent. However, the problem is solved by different variants of task management libraries (async, Q, etc.). In general, it is better to do the maximum decomposition of the code, to create countless functions inside functions is not a good practice.
Regarding the stones:
- Usually, all sorts of manuals and manuals like "hello world" use one socket to connect to the database. In practice, it turned out that if this socket hangs under a heavy request, then all other requests diligently wait for its release. Therefore, the first thing to do in a new project is to connect the database connection pool.
- It so happened that the number of simultaneous connections to the server exceeded one thousand, and suddenly there were inexplicable anomalies and failures. As it turned out, nothing terrible happened, and it was just necessary to allow the operating system to open an order of magnitude more file / socket descriptors.
- Memory for nodejs is better to be limited by startup keys and give more to the database (if they are on the same machine). Otherwise, nodejs is in no hurry to run the garbage collector (this is an expensive operation) and grows.
- Reloads of nodejs due to sudden crashes from bugs are solved with special libraries, such as forever.
- To prevent nodejs from crashing due to exceptions, you need to set a global uncaughtException handler that writes them to the log or immediately sends them to the soap to the responsible person.
- We must not forget to unbind event handlers at the end of the work of the object subscribed to the event (removeListener ()).
Regarding frameworks, we use express because it is beautiful, simple and we are used to it.

Answer 2

tech.yandex.ru/events/yasubbotnik/ekb-jul-2013/talks/970/ - I advise you to look at this report and look for other reports on nodejs from Yandex subbotniks. auto and sport in Yandex just on the node

Answer 3

I'll tell my story. Previously, my ideal application was a thick frontend + heavy WCF (asp.net) services. We, as decent developers, have created our own front-end framework. And they rejoiced until they received a tempting order, but one of the conditions was some clients with javascript turned off. I did not want to return to asp.net mvc, so I got acquainted with the node. The front-end framework has been redesigned a bit, and now all components fly here and there. And interestingly, we can limit the component to only the frontend, or if it manipulates important models, then only the backend. Another good discovery for us was iisnodemodule - we don’t even need to worry about all node clusters, logging, restarts (or node crashes), and plus everything works in parallel with WCF services. In general, we are still happy as elephants)

Answer 4

I would recommend making the movement in this direction phased.
1. leave PHP outside.
2. write sections of the calculation code on the node, make RPC access to them from PHP. In PHP, gradually replace calculations with node calls.
3. wait for the critical mass - and make a decision a) leave it as it is, b) change the architecture (put the node outside, etc.)

Answer 5

Not really an answer, but you might be interested:
www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/

Answer 6

Try the Impress application server - http://habrahabr.ru/post/194250/
For PHP developers, it will be more understandable than other frameworks, because you can make new API handlers (urls for AJAX requests) without restarting the entire system, just creating a file. Many issues have been resolved, multi-threaded launch, restarting individual threads on exit, logging, data exchange between threads, returning statics, caching in memory both statics and code and data that this code produces, cookies, good drivers for the DBMS, and much more , in general, everything you need to develop application servers.