M
M
Maxim2020-06-15 08:32:52
Node.js
Maxim, 2020-06-15 08:32:52

What part of the server is better to write in PHP/Java/Go/C#/Rust instead of Node.js?

What tasks in a REST API application are the most resource-intensive for Node.js? In other words, what part of the server tasks would be more profitable to write in PHP/Java/Go/C#/Rust instead of optimizing the Node.js application?
Give examples please.

Answer the question

In order to leave comments, you need to log in

5 answer(s)
E
Evgeny Mamonov, 2020-06-15
@max_shane

Maxim, I write everything described below based on personal experience, you can argue with some of my statements :)
One way or another, but the most resource-intensive task, almost always, is working with the database.
A few years ago I did Python, PHP, Node, Go benchmarks.
Two things were important for me:
1 - server response speed / number of requests per second
2 - service volume in memory, because the cost of resources depends on this
On the test, where the services did not make requests to the database - of all four, Go worked best with a decent margin, unfortunately I don’t remember the numbers.
But all this difference disappeared as soon as only one simple SQL query was added to the database, to a table with 10 rows. Against this background, the difference in response speed was less than 10%.
In other words, if your service works with a database, there will, alas, be no critical difference in speed between Go/Rust/PHP/Node/Java.
But it's another matter if it is important for us how much memory each service "eats up".
For example, you have loads and you need to scale horizontally, i.e. run, say 100-10000 instances of your service.
This is where it gets more interesting :)
One copy of Go occupied about 6mb in memory, despite the fact that Pytho + Django was about 60mb.
Node, I don't remember how many, but something close to Python.
Here already, when you have a lot of servers - the number of servers with Go you will have 10 times less :)
I know cases when from almost 40 servers with API on Node they switched to 2 servers with Go.
Partly for this and for a number of other reasons, I've been using Go and Python for the past few years.
Personally, I'm just mega excited about Go :)
Go is also ideal for writing network services, CLI utilities, etc.
For example, Docker, Kubernetes, and a bunch of other things are written in Go.
I've done this kind of thing in many different languages, and nothing like Go has produced code that's as beautiful and understandable as it works well enough.
About PHP, if you know it, you can write in it, if you don’t know, I don’t advise you to learn, at least because there is Python, the code is much more readable on it, there are more opportunities, vacancies with a normal salary.
I didn’t write in C#, so I can’t say anything about it.
I wrote in Java for several years, but I don't like it very much :) Especially when there is Go :)
If you learn Java, get ready for the fact that you will maintain Legacy code, or rather ... no code :)
But there are vacancies with good /p in Java is also a lot. At the very least, you won't run out of money.
Rust makes sense to use when you have a very large load and latency is critical for you.
For example, to display ads, you need to respond within 100ms, otherwise your ad will simply not be shown.
This is where Rust wins over Go by having Go periodically "failures" during garbage collection.
Otherwise, in my opinion, Rust will lose due to more development time, worse code readability.
On the other hand, if you have a working service on Node, then instead of switching to Rust, it would obviously be better to just make a C / C ++ module for Node and everything will fly + full control over memory allocation and release.
I have used such a scheme with modules in C / C ++ more than once in Perl.
It helped a lot, especially where it was necessary to clearly free up memory so that the scripts would not swell over time.
I hope this helps you in some way :)

S
Sergey Gornostaev, 2020-06-15
@sergey-gornostaev

It doesn't matter on what to write a spherical REST API in a vacuum. Languages ​​are not chosen according to this principle.

M
mayton2019, 2020-06-15
@mayton2019

Everything that the author wrote does not really matter. Languages ​​are not chosen in this way at all.
Any of them will solve your problem. And 99% of the choice will be determined by the expertise of your team
in relation to the PL.
And assess the risks of fundamental impossibility to do something. For example, running a background job or thread inside a Node process. This is an important point and a Liberrum Veto that can simply exclude a
language or technology from the list altogether.

A
Alexey Sundukov, 2020-06-15
@alekciy

In this formulation - none. Are you able and know the node? So write on it. Any problems? Solve specific problems within the platform. Have a problem that cannot be solved within the framework of this platform? This is where it's time to think about whether it's worth moving on.

R
razielvamp, 2020-06-15
@razielvamp

If by "profitability" we mean exclusively the speed of calculations, then it is "more profitable" to write any part of the server in Java, Rust, and other compiled, as low-level languages ​​as possible.
If you correctly do it right away in the bytecode, then in general there will be a "rocket".

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question