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:
Even better, NVM works on Linux, Mac and Windows thanks to nvm-windows.
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:
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.
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.
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:
Phing was used for three things in our projects:
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
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.
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.