Moving from PHP with Laravel to NodeJS with Express

One of my long term applications I’m working on¬†is¬†Financial.
I started it with a composition of:

  • DB: MySQL
  • Backend: PHP with Laravel
  • UI: Desktop interface with ExtJS

Early this year I added to the stack a Mobile UI created with React and Material-UI.

Now I feel it was not the right choice to bring PHP in this game as it involves too much of a ceremony and complexity to do development with it.

I believed that doing NodeJS was premature at that time and didn’t offer enough tools to develop an application like this easily, but things have changed in the meantime.

Here are the architectural changes I had to do during this migration:

  1. Routing with Express (before: Laravel Routing)
  2. Database interaction with Sequelize (before: Laravel Eloquent)
  3. Session with connect-session-sequelize and express-session (before: Laravel Session)
  4. Authentication with passport and passport-local (before: Laravel Authentication)
  5. Password hashing with bcrypt-nodejs (before: PHP password_hash)
  6. CSRF Token with csurf (before: Laravel CSRF)
  7. Config management with config (before: Laravel Config)
  8. md5 hashing with md5 (before: PHP md5)
  9. XML parsing with xml2js (before: PHP simplexml_load_file)
  10. Input validation with validator (before: Laravel Validation)
  11. Platform detection with UAParser.js (before: MobileDetect)
  12. Shell view generation with Handlebars.js (before: Laravel Blade)

Pull Request for reference: GitHub

Removing underscore.js bloat from your ES2015 project

I’ve been using¬†Underscore.js¬†for quite some time. It’s a very fast, lightweight library that provides a lot¬†of utility functions.

However, at this moment, with all the newest JavaScript features in place, we have lesser reasons to use 3rd parties like Underscore.js for “daily activities”¬†.

We all know that the latest ECMA spec¬†is not implemented in all the browsers, but that’s why we have¬†Babel. However, I’m optimistic that some day browsers will increase¬†their update cycles so much that we’ll get the latest features in no time.

To get back where we were, I’ve decided to clean up the Underscore.js bloat¬†because there were too many occurrences of _.each,, _.filter, etc. which are really a¬†useless¬†complexity added from my point of view.

There were two big questions I’ve asked myself:

  1. It’s obvious¬†that _.each/¬†should and will be replaced by Array.prototype methods. But why not look for other replacements¬†as well?
    As a lazy (efficient) man, I’ve browsed to see if someone already did a list for these and what do you know! This article¬†has a really nice list of replacements that I’ve used to refactor the code by¬†replacing with native solutions.
  2. Now I’ve replaced the bloat with some vanilla JavaScript code, but I cannot remove Underscore.js yet. Why? I still use lots of methods (like _.sortBy) that would require lot of duplicated code or making my own version of Underscore.js-like methods.
    To sum up: I don’t want to remove Underscore.js, but I also don’t want any other people to use again _.each, so what do I do?
    I’ve decided to write some linting code¬†that would fail a pull request containing code I don’t want to allow anymore.
    As I already have¬†ESLint¬†at hand, I’ll just have a new rule that lints this.
    I browsed several repos for plugins and I found nothing related to Underscore.js. But I discovered a similar ESLint plugin for jQuery.
    That was my inspiration and I came up with this:

I really think that¬†ESLint is definitely a big player in a strategy of controlling your project code’s evolution.

Hope this helps anybody out there! ūüôā