Using Config in your Workflow

What is Config?

Config is a NPM package that basically allows you to store configuration parameters in a separate file, and respond appropriately for different environments, such as staging, test, and production.

One it's many uses is the ability to obscure your application's sensitive parameters (database logins, API keys, backend addresses), as you can store all sensitive information in the config file, and then use .gitignore to not track it. This way you can still run your code base as a working local server, and still commit all changes, but your sensitive information is never publically viewable!

Using Config

Config accepts multiple formats, but let's use JSON, which I found the easiest to use, in my opinion.

First install config, if you haven't: npm install config --save

Here's the basic structure for an API key config file:

config/default.json

{
  // API Keys
  "APIKeys": {
    "Google": {
      "key": "abc123"
    },
    "Yahoo": {
      "key": "xyz456"
    }
  }
}

We can then pull the data from the config file thusly:

//First require the module
var config = require('config');
//Then pull the data from the file, and store it in a variable!
var googleAPIKey = config.get('APIKeys.Google.key');
var yahooAPIKey = config.get('APIKeys.Yahoo.key');

Don't forget to add your config file to .gitignore! e.g. *.log node_modules/ config/

Easy peasy!

Using config is easy! The JSON structure is very flexible. You can create custom JSON objects as you like, and traverse that object using simple dot notation in a string you pass to config.get().

Have fun!

Code Quality and Us

What is Code Quality?

All software engineers know this concept. The invaluable metric that defines whether someone's code is good or bad. Not all solutions are equal. There are dozens of sub-categories that can compose a code quality rubric - comment ratio, whitespacing, variable names, scope, performance, etc - the list goes on and on.

Simply Put:

I've found that the concisest definition of code quality I can think of is this: does your integration make it look like one person wrote the entire codebase?

There are contribution guidelines for most repos. This is because a seamless codebase represents one of the best performance benefits we can achieve: future engineers working on the project can quickly work with what you've made. When we write software, we don't write for ourselves, we write for our future teams. If you're the only one using IIFE's, it's going to stand out and slow down future development if it's not something people are used to. Comments, whitespacing, proper scopes that don't have global namespace soup, etc, all contribute to readability, and ultimately, more free man-hours for a team to make it better, whether its polish, optimization, or feature range.

Karma

Whenever I've gotten stuck on someone else's API, I use that frustration to push myself to build better solutions in the future. I think if we all kept in mind our future selves when we write software, the world would spin more smoothly. "Would future me want to use what I just wrote?"

Express.io

Introducing... Express.io!

The power of Express.js with WebSockets

I've recently started a new project that requires something a little different from the usual MEAN stack. I needed to route static resources (easy, with the power of Express.js) but I also needed to manage WebSocket connections for a thick-client setup. I found that while Express.io essentially takes the same amount of time to setup, it has syntactical sugar benefits that were beneficial to the project in the long run.

Examples

Let's look at examples of separate Express.js/Sockets.io, and then Express.io.

Express.js + Sockets.io

var express = require('express');
var app = express.createServer();
var io = require('socket.io')(app);

io.on('connection', function (socket) {
  socket.emit('news', { hello: 'world' });
  socket.on('my other event', function (data) {
    console.log(data);
  });
});

app.listen(80);

Express.io

app = require('express.io')()
app.http().io()

// Setup the ready route, and emit talk event.
app.io.route('ready', function(req) {
    req.io.emit('talk', {
        message: 'io event from an io route on the server'
    })
})

app.listen(7076)

I omitted the static file serving code from both because they were the exact same.

Thoughts

You will notice that combining Express.js and WebSockets.io uses essentially two different vocabularies - app.get(dir, route) for a Express route, and io.on(socketEvent, callback) for a WebSocket event. While not totally jarring, it did not hold a candle to the smoother Express.io app.get() and app.io.route(). I also liked that app.io.route callbacks mimicked the res.send() methods I had grown so accustomed to.

Any cleaner routing is a win in my book!

Bonus Round - "Realtime Routing"

Express.io features something it calls "Realtime Routing" - essentially the ability to route within a route!

From the express.io GitHub page:

app.io.route('customers', {
    create: function(req) {
        // create your customer
    },
    update: function(req) {
        // update your customer
    },
    remove: function(req) {
        // remove your customer
    },
});

And then on the client you would emit these events:
    customers:create
    customers:update
    customers:delete

Scaffolding for me has always been a subtle pain, and I expect to have to wire a lot of connections in the coming weeks. I look forward to using Express.io to slide through with ease!