Error EHOSTUNREACH When Connecting Local Node.JS and Database

I recently got this pretty obscure error called EHOSTUNREACH when trying to setup a local environment with node and a mysql database. I’d been using mysql on my computer for a few years but was only just starting to work with node so I chalked it up to some old setting tweak I’d made and was now causing a port conflict or something with node. When I later installed and setup MongoDB and had the same problem with a separate project, I realized it was probably something bigger (or at least more disruptive).

I found very little online about the error, which made it difficult to debug. Most searches turned up results for an ECONREFUSED error, but none of those solutions worked for me. Upgrading all my installs didn’t work. Reinstalling didn’t work. Separately, node could connect and the databases could connect. Running the app on another machine also worked fine, so it was obviously a problem in my environment.

In the end, after several hours of debugging I discovered the problem (not without lots of help). For some reason, my computer doesn’t like using localhost as the host for a local environment. Changing my node settings to explicitly connect to the database at the local ip 127.0.0.1 ended up fixing the problem for both database connections.

This is the error I was getting in my terminal:

.../node_modules/mongodb/lib/server.js:242
        process.nextTick(function() { throw err; })
                                      ^
Error: connect EHOSTUNREACH fe80::1:27017 - Local (:::49442)
    at Object.exports._errnoException (util.js:890:11)
    at exports._exceptionWithHostPort (util.js:913:20)
    at connect (net.js:849:16)
    at net.js:984:7
    at GetAddrInfoReqWrap.asyncCallback [as callback] (dns.js:63:16)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:82:10)
[nodemon] app crashed - waiting for file changes before starting...

…and this is the mysql setting I changed in my node files.

var mysql = require('mysql');
var connection = mysql.createConnection({
  user: 'local',
  password: 'local',
  database: 'mydatabase',
  port: 3306,
  host: '127.0.0.1'
});

Update:

I discovered the root cause of the problem above while recently developing a mobile app and running into problems running mobile simulators. There was some old setting left in my hosts file that was routing localhost to a weird IPv6 address. Updating to the following fixed all my problems:

127.0.0.1       localhost
::1             localhost

It’s always the smallest mistake that causes the biggest headaches isn’t? Hope this helps spare someone else the same!

Understanding Backbone.js

An attempt to provide a higher level understanding of the Backbone JavaScript framework as well as MVC architecture more generally. Exploring how it uses modules (Models, Collections, and Views) to separate out responsibility and how triggers connect it all together.

We recently had an exercise introducing us to the JavaScript framework, Backbone. The goal was to jump into a partially built application and fill in missing functionality ourselves. While the idea behind Backbone is to add structure to the code of an application, navigating through one built using the framework turned out to be extremely challenging. After finally managing to wrap my head around it (I think…), I wanted to share some of the key points of understanding.

What is a code “Framework”?

The goal of coding frameworks in general is to add structure to a code base in order to improve readability and clarity (so that, for example, someone else, even future you, can more easily jump in and built on top of it). This is done by building out your code into modules, each with a clearly defined division of labor and with each module keeping to the Single Responsibility Principle  as much as possible.

In Backbone, this is done using an MV* Architecture, which stands for Model View Architecture (the * is in place for a ‘C’ for “Controller” but these don’t really play a role in Backbone). Models and Views are the two main categories of modules in the framework, with each category responsible for a specific type of task. Models are Classes used to manage data and their state at any given time, whereas Views are the data’s visual representations. There’s also a third type of module in Backbone called a Collection, which are basically groupings of a specific Model type (you can think of them as an array of Model objects).

My goal in writing this was to convey the higher level concepts of Backbone that helped me to understand it better, so I won’t be going into the specifics of the code behind these modules (extra resources for that at the end of the post). To understand how these work, you can think of a To Do list. Imagine you have a Model for tasks. Each new task gets built, using the task model. This task model allows you to store the task’s state (complete/incomplete) since each task generated should have this capability. Your list of tasks would be a Collection of task models, and, finally, you would have a view that displays the tasks to the user, most notably reflecting its state (i.e. checked if complete).

So in this simple example, this structure seems great right? Nice separation of responsibilities, easy to see which block of code performs which operation. The problem that I ran into though is that as you build in more complexities, you have more and more interweaving modules. In the app we had to build functionality into, there ended up being around a dozen different modules of all three types and all interconnected with each other. This was all for a simple app with very simple functionality and just a couple of opportunities for user interaction. Mapping these relationships was extremely tedious. In the end, trying to figure out how everything interacted with everything else was an exercise in putting my brain through a blender.

Eureka Moment

Diagramming out how each module is connected is definitely a good place to start when trying to wrap your head around this architecture. I’d caution against spending too much time on this though. I went through a good two hours mapping out the code base I was working on and at the bottom of the rabbit hole the only thing I really felt I’d learned was how deep into the hole I’d gone… and that it was still mostly dark down there.

Triggers

My major epiphany came when I realized that “triggers”, or events, are the main currency of the Backbone framework (hat tip to my classmate Rahim for that phrasing). Basically what this means is that the thing that ties the whole structure together is a network of different event triggers and listeners. When an event on one module (almost always a Model) is triggered, it sets off a chain reaction of events, passing that state change across the different related modules that are listening for the initial trigger to be set off (these listeners could be on Views, Collections, or even other Models). Building on top of this, the best way to think of Models is as a sort of control panel that houses various triggers which themselves manipulate whatever is “wired” to them. So when you’re building up Models for your application or trying to navigate around someone else’s code base, understanding where the triggers are and what other models are listening to them is a very good place to start. Try and centralize these triggers as much as possible (remember, division of labor).

This key point became even clearer for me as we started moving into React, another JavaScript framework. I’m still getting familiar with it, but in React it seems like a lot of the complexity in Backbone (which comes from all the different, interconnected relationships) is abstracted away while the framework takes care of a lot for you in the background. In React, modules are more self-contained, with both states (i.e. triggers/listeners) and the visual representations (i.e. views) maintained within the same Class. Meanwhile, React equips you with helper properties and methods like render and set which take care of the triggering reactions for you. A good way to conceptualize it is that in Backbone the relationships can be thought of as graphs, whereas in React they are hierarchal like a tree. This makes the connections much easier to trace in React than Backbone, and so much simpler to untangle and as well.

Helpful Resources

While the official Backbone documentation is very useful and thorough, I wouldn’t rely on it too much while you’re still trying to understand the framework conceptually. Use it as an aid when you’re looking for something specific rather than as a tutorial on how to build with Backbone.

I found this article really helpful in starting to understand this new MVC way of thinking. In it, the author takes a very simple application, posting a message typed by the user on the page, written in normal JavaScript and step by step converts it into using a Backbone architecture by separating out its functionality into Models, Views, and Collections. In the end, the code went from 16 lines of JavaScript… to more than 40 using Backbone.

Obviously I’m still trying to wrap my head around all of this myself so there’s a very good chance that I mischaracterized something or was totally off-base altogether. So definitely caveat emptor as you read this. If there’s something I missed, something I got wrong, something you’d like to add to, or something you’d like to ask about, please feel free to share in the comments!