I’ve created the
pow-mDNS tool that helps accessing your Pow applications over the local network without any preliminary configuration. This means you don’t need to run an additional HTTP server (
rails server on port 3000 yay!) on a special port to load your web apps on an iPad, iPhone or any other computer.
You can install it via
npm install -g pow-mdns
To get started, head over to the GitHub page. However in case you're interested in how it works, please read on. In this article I'll try to explain what services and technologies pow-mDNS is using.
mDNS plays a key role in zero-configuration tools and based on my experiences, surprisingly not a lot of us knows of it so I’ll try to explain why it’s a great addition to toolset of a modern web developer.
Connecting the dots
I love pretty much everything that Just Works™. If you’ve been working with Rails applications you must have come across Pow, the zero-config Rack server that makes it incredibly easy to access your Rails, Rack (or even Node.js) apps locally under a minute. You just symlink your Rack application into
$HOME/.pow/ and then load up a special
.dev host that corresponds to the name of your application directory. And that’s pretty much it. No more
rails server commands, things just work out of the box.
If you don’t know what I’m talking about then stop reading and head over to the Pow website and see what you have been missing out on.
Pow from mobile devices
Pow is really useful when you develop locally and just want to fire up your application. But what happens when you need to access that app from other devices such as iPhones, iPads or other computers?
Pow’s mechanism relies on having a local DNS resolver that forwards requests to
127.0.0.1. Given the DNS resolver is local to your machine, the
.dev domains aren’t accessible from the network, only from the same machine that runs Pow itself.
To overcome this problem, Basecamp introduced xip.io, a magic domain that runs a custom DNS resolver on the pubic internet to provide wildcard DNS for any IP address.
This means we can use
xip.io domains to access our Pow applications on our local network. Given our app runs on
myapp.dev and our IP address is
192.168.1.107, we can fire up
myapp.192.168.1.107.xip.io from any device, provided we are on the same network. Simple.
Until your IP address changes…
Bonjour, monsieur Pow!
If you have been using OS X or an iPhone for a while now, you know these devices are capable of talking to each other without any preliminary configuration. This is made possible using mDNS:
The purpose of the multicast Domain Name System (mDNS) is to resolve host names to IP addresses within small networks that do not include a local name server. -- Wikipedia
Bonjour is Apple's implementation of Zero-configuration networking (Zeroconf) that locates devices such as printers, other computers, and the services that those devices offer on a local network using multicast Domain Name System (mDNS) service records.
Have you seen the list of computers on the local network in Finder’s sidebar or the shared libraries in iTunes? These are all made possible using Bonjour. Finder uses AFP (or SMB) to share files over the network and the iTunes music sharing is done via the DAAP protocol.
As you can see by now Bonjour can be used to advertise different services and so nothing is preventing us from sharing our Pow applications via HTTP.
In practice, this means we can stop having to look up our IP addresses at all times and won’t need to make changes to our DNS services either. Accessing our apps on the network is not longer tied to an existing, preconfigured local DNS server.
Using the services and technologies mentioned above, pow-mDNS allows us to access our web applications on the local network without any preliminary configuration.
As you probably understand by now, pow-mDNS is not in any way complex or revolutionary. In fact, most of the heavy lifting is done by existing services, such as Pow and xip.io.
Why I wrote this
pow-mDNS was grown out of the need of having a simple tool that would help us with synchronised testing of responsive designs on multiple devices.
There are existing tools that solve that problem, such as GhostLab or Adobe Edge Inspect, and I’m sure these help a lot of developers on a daily basis. However, these are also closed source commercial products and in some cases don’t necessarily work the way I want them to.
I wanted to provide an alternative to these apps, while making sure that Things Just Work™ out of the box and all components are freely available to anyone. (Yes, Pow and even the xip.io custom DNS server are open source)
There has been some ongoing conversation about baking mDNS support into Pow itself, but that has not yet materialised. (I’m also not sure if this should be part of Pow core, it could perhaps be done via a plugin so that it could be released and maintained separately. However there’s no plugin system in Pow, at least yet.)
pow-mDNS is just one of the components I wanted to build and there’s a lot of room for potential improvement.
My goal is to continue to provide open source tools to developers that provide exceptional user experience.
I’d like to explore the potential options to build a set of tools that could be used together to form an ecosystem of modern development tools, regardless of what kind of web application you are running. This would help us with synchronised testing, allowing decentralised teams to collaborate, etc.
So far, off the top of my head I can see the following possible improvements:
Baking LiveReload in
One of the best features of Adobe Edge Inspect is that it uses LiveReload to automatically refresh all clients connected. This is actually something that I’ve already done on one of our previous projects without the need of the LiveReload extension in Chrome or having the Edge Inspect app installed on iPhones.
Basically we have two options:
- To inject LiveReload.js on the application level, perhaps to create framework specific libraries (A gem for Rails/Rack apps, or a gulp plugin).
- Alternatively we could pipe the requests through an HTTP proxy that adds LiveReload into the HTML code.
I haven’t had the time yet to compare the pros and cons between these options but this is definitely see as one of the features that provide the biggest benefit.
Currently all Pow apps are advertised over the network and there’s no way to filter what is exposed and what is kept private. This raises a couple of security concerns. You might have some apps that you wouldn’t want to reveal over the network.
Creating an OS X menu bar app
I’d like to provide a way for designers and other non-technical people to access developer’s applications without having to install Node.js and all the prerequisites to run the app. This would involve having to repackage (or reimplement) some of the functionality of pow-mDNS in a form of a native Mac application.
I’ve been trying to create an app for this, but in the past Objective-C was giving me shivers and even with the arrival of Swift, it’s a little bit out of my capabilities yet. (Care to help?)
I’m a big fan of decentralised working, in fact I’m writing these lines in my Budapest office and getting ready to work for a London based development company, remotely. Needless to say, we are not going to be on the same local network and having to install, configure and then connect to a VPN is not something that I’d call zero-conf.
I appreciate this is a biggie and I honestly haven’t thought this through but I see it as something that I’d love to see working without the hassle.
These are all just ideas that I’ve been having in the last few years throughout my career and I’d like to see materialising. I’d also like to think that I’m not the only one who would make great use of the above, so in case you and I are in the same boat, then please leave your thoughts in the form of comments below or get in touch via twitter.
- The header artwork is made by Corey Templeton.
I'm a Ruby/JS dev/trainer with a focus on quality. An ex-Londoner, @terracycle, @ubxd, @lastfm. Follow me at http://twitter.com/attilagyorffy