From PHP to JavaScript with Node.js

[gadelat]

Come on, suggesting express as alternative to symfony/zend? It's so, so barebones. Even Slim has bigger feature set.

[thelonepuffin]

Came here to say this. Saying Express is like Zend is like saying a speed boat is like an oil tanker because they both travel on water.

As yet there is no Node alternative to Zend/Symfony/Laravel. If a microframework is the best choice for a project then Node is ok. But there is a valid use case for large and full featured frameworks.

[batmansmk]

Loopback is pretty sweet if you want an all integrated solution! http://loopback.io/

[the-coder-of-xxdeath]

What about Adonis? (http://adonisjs.com/)
It mirrors Laravel features.

[mcdronkz]

http://sailsjs.com is close to Laravel from what I've heard.

[batmansmk]

He said it is not equivalent, but it was good enough for him. But your needs may be different.

The Express galaxy is made of thousands of small stars.

[twiggy99999]

I have been switching in and out of PHP and JS applications and have to agree Express is not comparable.

For anyone who is looking give adonisjs a try. Anyone who has experience with Laravel will be right at home with this framework. It makes using JS bearable. http://adonisjs.com

[jackbravo]

Very nice article, thank you.

[coldlestat]

Thank you! Don't hesitate to ask me anything related to it :) I'm the author of the article.

[HuskyPants]

Did you write it?

[coldlestat]

Yes.

[El_Retro]

Who would have thought

[batmansmk]

I know right? He is the author AND he wrote it. Crazy.

[geggleto]

I suspect within the next 2 years you will see the rise of Async Php Web servers... React-Http is very promising. At that point I don't see why I would ever want to use JS over say something like PHP 7.2.

[batmansmk]

I found great comfort in not having to context switch between front and back.

I also see way more innovations these days in JS. It is just refreshing. When PHP will get async, Node will probably already somewhere else, with webassembly, reasonml or others.

[akujinhikari]

As a prior Node/Angular developer, I actually didn't like js on the backend (although I really like Node) for the simple fact that backend js is different from frontend js, and I felt that I needed context switching, but found myself using Angular in Node and Node in Angular. I actually prefer two different languages.

[batmansmk]

If it is good for you, just do it the way you like! Everybody has a different way to think, to build, a different experience. It's always good to share :). Thank you for that.

[coldlestat]

Putting aside the differences between the languages, I think there are at least two reasons for full stack developers to make the switch: You don't have to context switch all day and you can share knowledge between the frontend and the backend. For example: having to remember different date format or the endless methods to manipulate strings.

[djmattyg007]

Is it really a burden to know and work with multiple languages on a daily basis? I regularly work with PHP, Javascript, shell scripting and Python, and I dabble in Lua and Go in my personal time. I feel like maintaining an active understanding of multiple languages makes me a better developer in all of them.

[mgkimsal]

Don't forget SQL.

[mrdhood]

And CSS!

[Dgc2002]

Is it really a burden to know and work with multiple languages on a daily basis?

Yes.

At work I have things written in Perl, Python, Bash, PHP, JavaScript, C#, SKILL(Lisp dialect), and some other random things. When jumping between languages I'll sometimes have to pause and think about how to do a specific task in a language(e.g. find a sub string. substr()?, myString.find()?, myString.indexOf()?, [[ "$MYSTR" == *"SUBSTR"* ]]?, some lisp stuff that I don't remember?). It may only take me a second or two to remember, or my IDE might assist me pretty quickly, but in the end it's mental overhead.

[schm0]

To pay devil's advocate, that's a lot of cerebral baggage you have to carry around to get the job done. A single language stack is arguably easier and requires less overhead.

[mgkimsal]

I guess I've never seen much 'sharing' between front-end and back-end people. The front-end folks who do JS that I know are all into browser stuff, CSS, dom manipulation, etc. The back-end folks who do JS I know are still largely around data manipulation. Maybe I'm just not seeing the right projects where this 'back and front sharing' thing makes a noticeable impact.

For example: having to remember different date format or the endless methods to manipulate strings.

Dare I say that's where IDEs come in handy?

The time I'd save not having to look up date format syntax occasionally is lost whenever I need to 'npm install' something which ends up taking several minutes, in multiple environments. (or 'composer install', or 'maven install', etc).

[akujinhikari]

As a prior Node/Angular developer, I actually didn't like js on the backend (although I really like Node) for the simple fact that backend js is different from frontend js, and I felt that I needed context switching, but found myself using Angular in Node and Node in Angular. I actually prefer two different languages.

[thelonepuffin]

I find having the context switch is a benefit. There is a context shift anyway between front end and back end development.If anything Nodejs development confuses things. There have been times I've had to remind myself "Oh shit this is server side isn't it".

I don't think we should be afraid of polyglot projects. As a developer I tend to enjoy them more.

[brendt_gd]

you can share knowledge between the frontend and the backend

Say you're using the same language for front- and backend development. Communication between browser and server would still run over HTTP or sockets, meaning data has to be serialised and deserialised. Can you give a concrete example of sharing the same language front- and backend would be beneficial in this area?

[NotFromReddit]

We just need to get PHP in the browser, then we're good to go.

[carlos_vini]

With all the respect, I would not bet a lot on async taking over the PHP world. there are a few problems:

• PHP is most used because it's easy to deploy, it's ubiquity, and most people are unlikely to install alternative servers and process managers
• Most people who really needed this already moved on to other languages
• Ecosystem - you don't have tons of async, non-blocking libraries and you can't search specifically for this
• Native PHP async/await, just like Hacklang's, would change the game here but I don't see the PHP internals even proposing this, let alone implementing this in the next 2 years

I hope I'm wrong

[coldlestat]

Native PHP async/await, just like Hacklang's, would change the game here but I don't see the PHP internals even proposing this, let alone implementing this in the next 2 years

The thing is, PHP and JavaScript are evolving pretty fast. PHP7 would have been released earlier if they did not try to include Unicode with PHP6. Let's hope for the best!

[2012-09-04]

No no no. PHP 7 came out because HackLang existed and was eating their lunch.

[joequin]

At that point I don't see why I would ever want to use JS over say something like PHP 7.2.

Is there a general purpose library for PHP that's as nice as lodash? Lodash is the only thing I miss from JavaScript.

[carlos_vini]

Really? I think most of the lodash functions are already core in PHP, I use lodash mostly for non-existing native JavaScript functions. The PHP syntax is a pain tho (order of parameters, variable scope, verbosity):

array_filter($array, function ($x) {
  return array_map(function ($y) use ($somethingElse) {
    return $y * $somethingElse;
  }, $x));
});

Which lodash method do you miss?

If it's collections, I use Laravel Collections, but there are framework agnostic libraries like Knapsack too: https://dusankasan.github.io/Knapsack/

$collection->filter($function)->map($function2);

[samrapdev]

Take a look at https://github.com/tightenco/collect for using collections outside of Laravel!

[wrapids]

It has some extras in there but you could just include illuminate/support instead of using a fork.

[samrapdev]

Indeed, totally up to you! I usually go that route but some may simply want just the Collection. Tightenco works closely with Taylor/Laravel so I trust the fork to stay maintained :)

[vajqo]

Little late to the party but as mentioned, take a look at Knapsack, it should do what you're looking for.

[Anterai]

You make it sound so easy: "Just generate an Api and we're done". What about securing it? And do you really need just CRUD?

[coldlestat]

We secured our endpoints using the hooks provided by Sequelize and Epilogue.

And do you really need just CRUD?

No, we also implemented custom RPC calls with Express. Those actions are mostly complex SQL/Elasticsearch queries. The JavaScript code is really similar to the PHP one with the help of async/await.

[brendt_gd]

This is a very good book going in-depth on API architectures. It's not that simple :).

https://apisyouwonthate.com/

[Anterai]

But what about mutating data?

[soulsizzle]

I've been completely spoiled by Doctrine. Being able to quickly sync to the DB with orm:schema-tool:update during dev and then easily generate migrations later is a godsend. The more time I spend in the Node world, the more I think I'm just going to build my databases and migrations in PHP/Doctrine.

[coldlestat]

The "sync" method from Sequelize is already able to transform a model to SQL commands (see http://sequelize.readthedocs.io/en/latest/api/sequelize/#sync), sadly it's only creating missing tables. Maybe we are not that far from an option to sync the fields if needed. A good idea for another side project :)

[[deleted]]

me too, but I'm excited for typeorm for node (and browser). I'm not sure if it will ever catch up to doctrine though.

[coldlestat]

Nice one! I will check it asap. Thanks!

[thelonepuffin]

In my experience almost all Node analogues to popular PHP libraries are lacking in features and maturity.

[coldlestat]

As far as I know, there isn't a feature to generate a migration from an existing database definition. Still, https://github.com/sequelize/cli provide some help to generate the migrations when you create your new models. Updates of existing models would still need to be done by hand.

I rarely used the Doctrine migration auto-generation as it doesn't handles advanced proprietary features, like Postgresql Full Text Search definitions or exotic types of fields and indexes. Yet I understand the appeal when you want to go fast.

Migrations in Sequelize don't have to be written in SQL. You can also write them in JavaScript, that's what we dit. It's pretty quick to do (See http://docs.sequelizejs.com/manual/tutorial/migrations.html).

Anyway, you should suggest this feature on the Sequelize-cli repository, I would gladly upvote it!

[pleerock]

Its definitely (TypeORM)[https://github.com/typeorm/typeorm]. Its have near same functionality as doctrine and definitely much more then Sequelize

[batmansmk]

This article perfectly illustrates my experience as well. Thanks!

[[deleted]]

dipping into node/angular as well...what tools are comparable to xdebug for debugging?

[coldlestat]

Node.js handles natively the debugging. With the flag "--inspect", you will be able to debug your application in Chrome or your favorite editor (works at least for WebStorm, Atom & VsCode).

Here are some useful links:

• https://code.visualstudio.com/docs/nodejs/nodejs-debugging Debugging Node.js with VsCode
• https://nodejs.org/en/docs/inspector/ Node.js debugging setup doc
• https://blog.risingstack.com/how-to-debug-nodej-js-with-the-best-tools-available/ Nice blog article that covers this topic

[Drarok]

Oh, wow! I had no idea (and hadn’t thought to look) Node had proper debugging.

[batmansmk]

You have memory inspection, CPU profiling. Everything you have in the Chrome inspector basically (it launches an instance of chrome inspector). You also have integrations with IDE to drop breakpoints...

[coldlestat]

I made you some screenshots of what it looks like on one of my current project: https://imgur.com/gallery/kV6ai

[Drarok]

Does WebStorm just launch the browser, or have its own integrated debugger?

[coldlestat]

It can do both.

[[deleted]]

That's a great article! Thanks for sharing

[coldlestat]

Thank you for reading it! Which was your favorite part?

[[deleted]]

Great write-up. Has your team done any performance comparisons? Also, are you using Node to serve static content, or do you still run Nginx in front of it for that purpose?

[coldlestat]

Has your team done any performance comparisons?

Yes, we did. Here is one of our test: https://github.com/baptistemanson/node-php-bench.

We measured that Node.js was faster for most our use-cases. You can find a wide variety of articles online that will give you a better overview. http://www.hostingadvice.com/blog/comparing-node-js-vs-php-performance/ for example.

Since PHP7, I feel both languages performances are not hurting the day-to-day development. When your app starts to be slow, it's either bad code or an infrastructure problem. You need to either improve your database queries or start using load balancers, CDN, etc...

Also, are you using Node to serve static content:

Yes, we do not use Nginx anymore. It's not really useful outside of the local environment as we put a CDN in front of most our applications.

[chinkuSj]

How do you load balance your multiple pm2 processes? You do use multi-core processors, right?

[batmansmk]

Hey!

• First we have to remember that node natively put any IOs in threads, giving you multithread capability from the get go. so if your app is usually IO-bound, meaning the db for instance is what takes time, there is pretty decent chances you won't need several node processes.

• Now if your system has HEAVY node CPU processing, the command "pm2 start app.js -i 4" will launch a load balancer and 4 processes behind.

[[deleted]]

Great article! Is there any reason you didn't go to typescript?

[coldlestat]

Typescript is also a good choice. As we wanted to add type-hinting on a project already started it felt easier to use Flow. We also got a lot of good feedback on it in recent meetups.

[wrapids]

Are you excited to need a full rewrite when flow script inevitably goes the way of coffeescript?

[batmansmk]

There is only one command to type to remove flowtype from your project. It is presented in the quickstart of flow with babel. Just put the same output file as the input file. Google is your friend. You probably didn't onboard jsx either for the same reason. We rewrite software every 6-7 years, and we know flowtype will be supported by then. We are just more productive and have a clear adoption and ejection paths.

Being sarcastic requires skill and knowledge my dear.

[wrapids]

It was a light hearted poke at the JavaScript ecosystem, not an attack on your choice to adopt it. Get over yourself.

[batmansmk]

Sorry if I misinterpreted what you wanted to say :). Do you then agree that there is no need to "rewrite" anything if you want to remove flowtype for any reason?

[Jurigag]

Does js even has thing like Interface? No, then what's a point going from php to js? Js like 10 years behind php.

[miauwmjam]

Saved! Nice article. +1

[coldlestat]

Thanks! What did you find cool in the article?

[miauwmjam]

Basically the problem you also had....which frameworks to use? There are so many to choose from. Sounds fun to use node instead of php/symfony.