Is anyone here prefers Node over PHP for Backend?
For further actions, you may consider blocking this person and/or reporting abuse
Is anyone here prefers Node over PHP for Backend?
For further actions, you may consider blocking this person and/or reporting abuse
Oldest comments (71)
Websockets my love🙂
Is PHP considered as a programming language, compared to Node.js?
Yes, PHP is considered as a programming language. NodeJS too.
As far as I understand, Node isn't a programming language, JavaScript is. Node is a runtime environment that lets you execute JavaScript outside of the browser.
Exactly. A fair comparison would be node vs roadrunner for php. Even fpm isn't really a proper comparison since it only connects prerouted requests for php scripts with the php interpreter.
The mess is that there are technically 2 php interpreters, php cli and the one tied to fpm, both configurable separately.
It is more about your personal experience and feeling.
Both. I am a PHP developer and I decided to start a Quasar + Firebase project for learning purposes. It is already being a year me working on this project and now I deep stuck with decision how to proceed. I need now to add job queues and proper logging. Probably it is also better to have own database aside.
For now solo, but it should be scalable.
If you know how to do this on PHP, I will go Node just for the sake of learning.
Dockerize your environments and use any of the many queueing systems to manage your processes. E.g. RabbitMQ. I'd stick with php, it has its quirks but I love it over all other languages personally.
I prefer PHP.
Symfony or Laravel?
Vanilla MVC.
No frameworks?
No frameworks - some thin boilerplates only. PDO for databases, XSLT for templates. Model 55 lines, router 10 lines. Without any HTML inside.
Node.js is a JavaScript runtime and PHP is language !! PHP vs Javascript or you can compare Nodejs vs Zend Engine. be productive and avoid comparing languages .. all languages are good ...
My question is not about language, but about Server-Side Environment. How would you let your server handle request?
P.S. Should I put PHP-FPM in original question instead? :D
You should really make your question clear as to the scope of the expected answer.
You can mention fpm, sure, but fpm is simply the interpreting engine.
As to how to let the server handle requests, it's more about what features you want and whether you have external constraints from other systems in your stack.
Theoretically both node and fpm benefit from a reverse proxy or lb in front of them. The downside of fpm is that it needs a compatible web server as opposed to node.
Fpm only interprets php code, so the proxy in front needs to route those requests for php files and be able to serve non+php directly, unless you want to write a generic we server in PHP (not efficient). Therefore php works with nginx or lighttpd unless you go modphp and use apache with the embedded module (where prefork raises questions on performance VS the multithreaded nature of nginx)
Node has no such constraints. It can work with plain proxies like haproxy or even serve requests straight up (but you would need to pay attention to stuff like security).
In a containerized environment, php shows some limitations in that nginx +fpm is a bit of a pain to setup efficiently (think kubernetes) and you end up using roughly 3 lb's in front of fpm, nevermind the inherent networking overhead (usually I go with apache there)
Node is easier from this perspective, but switching ecosystems coming from php is not that easy.
Myself I ended up going with Roadrunner for php, as it is wrapped in a very efficient golang server + enforces psr compliant requestd/responses
If you would start a new project, what would you make as your backend? Node or PHP? Express or Laravel? Let's say you write a REST API, what stack would you use and why?
I would make my decision based on the goal. For example I have projects that leave a lot of room for learning. I would go with express in this case just to improve my knowledge, but I would also use it in cases where node packages may be superior to php (in case of grpc for example)
Otherwise I would use php but I would not use any of the major frameworks (I have a performance comparison of returning 100k json encoded rows from two related tables, Laravel is the worst performer of all).
I would favor a microservices framework like Swoole if I weren't inclined to make a monolithic API. Otherwise I would use a microframework like Symlex but nowadays I sort of favor a custom solution built around a fast router (there's nikic but also the phpleague router). For an API there aren't many requirements: fast router with Middleware support, DI container (phpdi is excellent) and maybe doctrine for a strong orm with several layers of caching. Of course, logging and some metrics/observability would be nice.
I have a sort of personal 'framework' that rivals symfony 5 in performance but it still lags behind the likes of ubiquity 2 and symlex.
But my main requirement from a php stack would be to handle routing for psr requests and responses and neither symfony nor laravel do that.
This comes from the fact that nowadays I consider it mandatory for a php api to be deployable with roadrunner (symlex is built for roadrunner compatibility), in this case php blows node/express out of the water and can close in on rust performance for example.
I wouldn't use either for grpc... If you're interested in container orchestration like kubernetes, I might use node for it. You can't use grpc+cluster modules together iirc.
Server Side PHP is the way to go.
dev.to/brewer1_jane/why-php-is-the...
Node if you want to do cloud work.
How would you implement state machines in Node? I am looking for a solid alternative to Symfony Workfow Component.
Depends on what you are trying to do... I use refund patterns.
Neither or it depends.
I prefer Php at backend because it easy for beginners...
But NodeJs is superb when it come to backend...
I prefer PHP and Laravel as backend, and also a JS framework as fronted like VUE. Laravel is really nice, easy, handy and secure to develop a mid range project. I have to say, I love it!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.