It's just that you are used to PHP. Async callbacks can be flattened with either ES6 generators or async/await by using TypeScript (Both of which require transpiling. nodejs alone would understand ES6 without it though.)
It's far better to do background tasks with its parallel capability.
The bigger concern is nodejs app server holds states between requests unlike PHP and as such when you define a static property on a class, it's held between all subsequent requests not giving you a clean state.
I'm trying to get used to nodejs for frontend as well but you should delegate db logics down to database triggers, so you don't have to duplicate logics between different languages if you have multiple or change language later on. Same goes for keeping config files in ini format or other language agnostic format.
> Async callbacks can be flattened with either ES6 generators or async/await by using TypeScript (Both of which require transpiling. nodejs alone would understand ES6 without it though.)
I'm no stranger to Node.js. We use it in production for all of our real-time/async stuff. The new ES6 features async/await are cool and all, but it's a late addition to a language that was clearly not designed for synchronous code. If you use them, you just end up with bloated, complex code. For an API, I think Node.js is the wrong tool for the job, personally. PHP is a better fit, IMHO. For real-time/async stuff, it's a different story.
It's far better to do background tasks with its parallel capability.
The bigger concern is nodejs app server holds states between requests unlike PHP and as such when you define a static property on a class, it's held between all subsequent requests not giving you a clean state.
I'm trying to get used to nodejs for frontend as well but you should delegate db logics down to database triggers, so you don't have to duplicate logics between different languages if you have multiple or change language later on. Same goes for keeping config files in ini format or other language agnostic format.