Tag Archives: node.js

Building your web app on the fly with Heroku

We all know that Git is the only way to deploy apps to Heroku, right? (Nope!) But the thing is, as good Git users, we don’t want to add our compiled stuff to source control. But our apps won’t work without them existing on the deployed app, right? That’s why we’ll want to build the stuff on the fly in Heroku’s servers themselves with an npm postinstall script. In fact, Heroku recommends this in their node.js support and best practices articles.

But how do we get about doing this?

Creating a build pipeline

First, we need a functioning build pipeline. We might have this setup, which copies Bootstrap’s CSS files to a certain folder, for example:

// package.json
  "scripts": {
    "copy": "cp -r node_modules/bootstrap/dist/css app

This requires that we have bootstrap as a devDependency:

// package.json
  "devDependencies": {
    "bootstrap": "4.0.0-alpha.2"

But then, these dev dependencies won’t get installed when they get deployed to Heroku. Now we have a dilemma. We can’t build these on Heroku since they’re dev dependencies. But they are dev dependencies, we don’t need them in our backend. So should we make them dependencies?

What should we do now? One option is, definitely, to make bootstrap a non-dev dependency. That way we can make sure the bootstrap package is installed when our app is deployed to Heroku.

The answer I came to after sitting under a tree to attain Heroku/node.js nirvana is to make a build script to install these build dependencies on Heroku. And also introduce the concept of build dependencies.

And oh, there’s no tree.

Build dependencies

build dependency
A dev dependency that is used to build an app.

So before building, we should call this script to first install the build dependencies we need. The script installs the build dependencies we have. But first, we need to list what our build dependencies are. To do that, we can use ye olde package.json. We can do it in the same format as the standard format for dependencies and devDependencies but since I explicitly defined build dependencies as a subset of dev dependencies, we could just specify our build dependencies as an array.

// package.json
  "buildDependencies": [

Now my script goes something like:

// install-build-dependencies.js
'use strict'

const pkg = require('./package')
const ChildProcess = require('child_process')

let bd = pkg.buildDependencies
bd = bd.map(dep => `${dep}@${pkg.devDependencies[dep]}`)
bd = bd.join(' ')

try {
  ChildProcess.execSync(`npm install ${bd}`)
catch (err) {

Putting it all together

Now we’re almost done. Do I still need to do this? Presumably, you’re already a Heroku dev.

// is-heroku.js
process.exit(isHeroku ? 0 : 1)

// package.json
  "scripts": {
    "postinstall": "node is-heroku && npm run heroku || exit 0",
    "heroku": "npm run install-build-dependencies && npm run build", // depending on your setup, you might have some other stuff here. I know I do.
    "build": "npm run copy",
    "install-build-dependencies": "node install-build-dependencies.js"

Reducing your slug size

Now you’re using this flow and you might wonder: I don’t really need these build dependencies while the app is running, right? What we can do is actually uninstall them after building. Doing so might significantly reduce your slug size. It’s the same script as above, just replace install with uninstall. Here’s the updated heroku script:

// package.json
  "scripts": {
    "heroku": "npm run install-build-dependencies && npm run build && npm run uninstall-build-dependencies"

Runtime dependencies (bonus!)

Maybe you have some “dependencies” that aren’t actually required dependencies. Maybe things like forever. Or maybe you’re just like me that likes using babel-cli on production code without caring about compiling them. I would like to define these runtime dependencies.

runtime dependency
A dev dependency that is required to run the app when deployed.

At this point, you should really know what to do with these now. Just do some copypasta on the things above. Only, obviously we shouldn’t really uninstall them after installing them.

Let’s finish this post

And that’s it! Hopefully you’ll gain enlightenment on some of the things I’ve shared on this post. This is the flow that I use myself on my latest project on Heroku. Which I totally forgot to share here. Anyway, thanks for reading, and I hope you’ll find Heroku/node.js development fun too.


Why the MEAN stack is mean (bad!)

While I have been browsing for freelancer gigs, I can’t help but notice employers actually requiring construction of a MEAN stack-based website. And this is actually bad! Companies and employers should not require or fully rely on a specific methodology to do things—after all, all roads lead to Rome. (For lack of a better saying? Help me on this one, I suck at writing.)

M: The story of the database

So you’re a company and you decide to move towards node.js development. After all, node.js is awesome and all. From a PHP-based workspace, you’d probably be using MySQL for your projects. Well guess what: MySQL is still a perfectly valid database solution for node.js apps. If instead you’re from a Windows environment, you’re still in luck: SQL Server is still a perfectly valid database solution for node.js apps. Every database was constructed with specific needs, after all. One such need is the deprecation of a query language to interact with the database. Thus arose NoSQL databases, such as MongoDB. Uhmm. Yep. Feel free to go on with MongoDB if your heart tells you to do so.

E: The story of the webserver

Ah. Express. I can tell you, I have used Express in the early days. But did anyone tell you how hard it is to reorder its varying middlewares? People of the node.js land have been constantly switching between middleware-based chaining and configuration-setting time and again. Alas, for Express, it was very hard to do so. Still, Express is solid and established in the node.js community as a standard webserver. But, have you heard the story of a certain company who got fed up tweaking Express and ended up developing their own webserver module? Yes, Express is good, but are you sure that’s want you want? What if you want streaming? What if you only just needed Connect? What if you just want to serve up some static files? Did you really need Express?

A: The story of the view

And now we temporarily depart node.js land and set sail to the far-off land of Bower. Back at the port, did you ask yourself: what’s Bower? Did we really need Bower? Yes, as an npm fanboy I can put a big black no to that. But other front-end developers had a need for other things, hence Bower. Bower’s functionality is still valid though. Throw in a bunch of files and a bower.json, voila, a Bower package. (Which is their own standard… package.json is from CommonJS.) But seriously, let’s get back to topic. I haven’t worked on Angular before, but I can more or less see what it can do from its home page. But really, Angular is just another tool that transforms data into a front-end view—a markup language that your web browser will understand. And to that regard, there are many modules on npm that already do just that. Of course I should mention my favorite, Jade. There’s Handlebars, Coffeecup, (I probably missed a lot of popular ones here…) that are awesome. And they are all equally valid options to render a view on the front-end.

NB: At the time of writing I am aware that Angular has landed onto node.js land. However, the MEAN stack has been popular before that and required Bower for it to be used.

N: The story of the executable

Let’s face it, companies: PHP sucks. Programmers don’t want to delve into this suck-hole. That’s why Facebook invented the Hack programming language and HHVM. Most PHP applications are single-threaded in nature and built with being run in Apache in mind. PHP did not have a webserver utility of its own until such a time when it’s not even relevant anymore. And imagine if someone opens up your website in 10,000 tabs in one fell swoop. You’d actually see a swarm of php.exes running in your operating system. Have you heard of bug #29992? I have struggled with it, and if you’re still a PHP developer, learn how to live with this nightmare: it’s a wontfix.

So a recap of why people love node.js: It is asynchronous in nature, and it uses the awesome V8 Javascript engine. Though limited to a single-thread, that should not stop you from forking it into other processes, which you should really do on another CPU or server. That said, IIS has been ahead in the asynchronicity game, though I don’t imagine Linux fanboys becoming Windows fanboys. Did I mention that node.js is cross-platform?

Problems coming from other full-stack methodologies

Yeah, we all know what the LAMP stack is. Linux, Apache, MySQL, PHP, we get it. The LAMP stack really just had one major problem:

Windows programmers.

Yep. It makes sense, right? You may be a PHP programmer, but in the end you’ll encounter Linux-only things and shit. And that just won’t work in a Windows environment. Another problem I experienced is Perl. Perl never really clicked to me. I didn’t know how it worked.

Either way, MEAN stack or not, I like that people are moving away from PHP. End the tyranny of PHP!


Having a standard way of doing things is great for portability and consistency. It will also be easier to find programmers who are experts on doing such things.


It has been hard for freelancers like me to find clients who don’t require the MEAN stack in their projects. node.js programmers should be free to npm install whatever shit they want to install.

Let me leave you with something to comtemplate with: meanjs.org’s package.json.

Why I like node.js

Months ago I stumbled across this and though, meh, it’s just another one of those dumb programming shenanigans. Over the last few weeks, I got to try to program with it. But before we go there, let’s stop and define what node.js is really.

Node.js is a program. It exposes a framework (an API), on top of which you can program using Javascript. Other than that, it boasts of this framework having an asynchronous nature, which we all know is better than synchronous sh*t.

I have crafted this mini table for a quick comparison. NB: These are all purely my opinion.

Programming language Javascript! (No, node.js is not a programming language!) Visual Basic or C# Freaking Java!
Program (compiler or interpreter) nodejs.exe I don’t know, MSBuild? Freaking javac!
Framework I don’t know, did they give it a name? The glorious .NET Framework Freaking JRE?!
Your friendly neighborhood IDE PhpStorm, Freaking NetBeans?!??!?!, Visual Studio (!) Visual Studio Freaking NetBeans?!??!?! Or Eclipse?
Community resource pool (?) Plugins? npm Nuget ????

Now that’s done, let’s have my answers: why like node.js?

  1. It’s freaking Javascript! It’s a language we all know and love! (It’s a C-based language, which most of us know, but scare most beginners, but hey, you can always alleviate that if you’re into language transformers like CoffeeScript.) It’s the language your server tells your client user agent to do! Now, it’s the language you write your server program in! That’s right:
  2. It’s your freaking own server program! Yes, unlike Apache and PHP, which are separate web server and interpreter, node.js allows you to be free and write your own! Although this creates an issue for hosting providers that might not want to give their customers that much freedom. Although there are some who are willing to give developers a chance. Note that node.js doesn’t have a built-in web server of its own, but it has an HTTP library which can get you started. And there are always libraries that can simplify your intended task.
  3. Yes, and with npm, installing third-party tools are a breeze. Just like apt, it takes care of all the dependencies your third-party library might require.
  4. It’s based on V8, the same Javascript engine used by the awesome browser Chrome! If you’re not familiar with what V8 does, here the thing: V8 compiles Javascript code into freaking native machine code. What this means is that when it’s done compiling, your code will run blazingly fast once it starts!
  5. It’s already in the intro, but it’s based on a freaking asynchronous API! What this means is that when some code reads a file, that code can wait for that I/O operation to complete while other code consumes the precious CPU cycles! This can be really useful especially in the website hosting context where many users can connect simultaneously to your website.
  6. Write a small script and it should just work, whether it’s a simple console.log("Hello World");, a demo to show to your students (given you’re a teacher? Probably…), or just to show off your m4d w3b scr4p1ng sk1ll2. Because Javascript is a freaking scripting language!

As node has many good things, it also has some bad shortcomings. Let’s take a short look at that:

  1. This really is for JS and not node: I am really lamenting the lack of an “await” keyword for JS. It would be really useful since node has an asynchronous API. Right now the closest we have for that is Q.async + ES6′ yield.
  2. Yeah, we all know Javascript, but only because it’s an ages-old programming language. There are a couple more advanced programming languages out there, Visual Basic being my (past? :O </3 oh no!) favorite, Ruby (psssh… only Taric uses this), and Python (Who uses Python anyway? I don’t know… NASA? Freaking Google?) that addresses many of the older languages’ shortcomings. But as these are actively developed, so are the oldies. I do hope Javascript catches up one day. Fingers crossed.

And that’s it! This concludes my fanboyish post about the freakishingly awesome node.js.