When I was a beginner in PHP, I embedded it in HTML files. My code was a mess. Therefore I started using frameworks to try organizing it: ZF1 and ZF2. With time passing, API-first approach left me with a server composed of a generated REST API and a few hundred lines of custom code.
As only a minor part of our projects was in PHP, a question arose; could we get rid of it? And if we could, what would be the cost and the benefits? In this article, I share my experience for those, like me, who want to move out of the PHP world and embrace the JS FullStack with solid grounds.
I will present you in this article mostly my journey on the server side from PHP to Node.js, and won’t talk about Webpack, React and other JS frontend technologies.
The stack evolution
How to install Node.js properly with NVM
Relying on the OS package manager or manually installing Node.js quickly led us to a lot of problems when we tried to switch versions. So we used NVM.
It's very easy to setup:
Once installed we were able to:
- Install different Node.js versions on one system with one command
- Switch seamlessly between those Node.js versions
Even better, NVM works on Linux, Mac and Windows thanks to nvm-windows.
- Promises (now built-in in the language)
- Destructuring & spread operator
- Modules and module loaders
- Maps / Sets and their weak versions
- Async / Await
From Composer to Yarn
Composer is a really nice tool but is slow. NPM has the same problem, so we picked Yarn instead. It’s a faster alternative to NPM.
On my last project, we had about a hundred dependencies. Among our team of 10 developers, we had at least 2 modifications of the node_modules folder per day.
(10 dev + 3 env) * 2 install/day * 60 days * 3 min/install = 78h
Indeed, two weeks were spent looking at loaders and reading Reddit. 3 minutes is long enough to add up to the cost of the project but too short to switch to another development task.
By bringing down the install time from 3 minutes to 1 minute with Yarn, we saved 46h of focus! That’s a good deal if you ask me.
The code will speak for itself. Here is a minimal example of an API Based on:
- Sequelize, an alternative to Doctrine
- Epilogue, an alternative to Apigility
With a few lines of code, we got a configurable and extendable REST API.
After having generated more than 50 API endpoints with Apigility, we were convinced that generating REST endpoints was possible AND efficient.
Epilogue generated our 10 endpoints without any problem. We were able to plug some custom code in the default workflow to handle complex rules, like user rights. What couldn’t be generated has been developed as simple Express RPC endpoints with the help of Sequelize.
It is true that Zend Framework 2 has way more features than Express. But Express has been elegant, lean and sufficient for all our needs. We didn’t miss anything.
I miss my types: Flow to the rescue
The ability to add input and return type hints to our PHP scripts, only when needed, was one of the features I loved the most in the language.
For many years I was thinking that there wasn’t a way to have the same support for types without committing to move to TypeScript.
I was wrong.
Flow is an easy to install tool:
It’s an easy opt-in, we just had to add a one-liner at the top of the files we wanted to track:
/* @flow */ or // @flow
Then, the command "flow check" gives a full report based on the inferred types.
What if my server crashes? Monitor it with PM2
With PHP, a crashing script meant a request not served. With Node.js, if the server crashes, the website is down. So we had to manage our processes.
With a lot of hearts as it’s my favorite pick from this article
While having the benefit to be installed through Yarn, PM2 has other advantages. It supports all the Supervisord monitoring features and do more. It tracks the load and the memory of each processes and can be configured to reload them when their code change.
“pm2 monit” will give a detailed view of what is happening for each process in real time. Also, logging felt easier as we could, by default, use the native console.log()/.warn()/.error().
Even better, while Supervisord scope is limited to the management of the processes, PM2 can also replace some deployment scripts with a simple configuration file:
Configure your project with .env
Phing was used for three things in our projects:
- Configuring the project
- Storing useful commands
The scripting part of Phing was not worth tooling anymore as all our scripts were, either linked to configurations of software outside of the PHP world, such as Supervisord, which we do not have any more or could be made as independent shell scripts in a few minutes.
At the end, the only role Phing would fulfill would have been storing commands and aliasing them. And this is wonderfully handled by Yarn (or NPM):
So we could get rid of Phing entirely and call our commands like this:
yarn run db-migrate
Use good Open Source editors
When developing in PHP, I decided to use PhpStorm, a commercial IDE, as free ones felt slow and lacked plugins.
So far, we've had a great experience using VsCode. It’s fast, has an awesome autocomplete engine and has a great community.
The ability to define which plugins are used on the project and to share their config is awesome. Anybody can, in one click, start coding right away with all the plugins pre-configured.
Get rid of manual linting with Prettier
In PHP we had something awesome. The PSRs. Those standards are really useful to define how the code should be written.
We configured our IDEs to follow PSR1&2. As there was no autocorrect feature, it was still up to everyone to enforce it. It wasn’t a great success.
No more debates, no more training, no more useless time spent on merging style-only modifications.
Everyone on the team used it and LOVED it! Coding the strict minimum of style while we let Prettier take care of the details was awesome.
- Our stack is easier to install and deploy
- We don't have to context switch between languages anymore
- We are no longer relying on complex install scripts
- It required a lot of research to establish a stack that matches our needs
We were able to quickly generate an API server like we used to do in PHP. I did not feel like leaving anything behind during the transition, all the tools we switched to were equivalent or better than before.
We want you to take the plunge and succeed in this transition. Don’t hesitate to contact us if you want more details or have some troubles with any steps.