Running a web server on the front-end

The introduction of TCP sockets support in Firefox OS made it possible to run a web server from the front-end, and all is written in JavaScript. Think of having something similar to express.js... but running on a browser (because after all, Firefox OS is a superturbocharged browser).

Again, JS server superstar Justin d'Archangelo wrote an implementation of a web server that works on Firefox OS. It's called fxos-web-server and it includes a few examples you can run.

None of the examples particularly fit my use case--I want to serve static content from a phone to other phones, but the examples were a bit more contrived. So I decided to build a simpler proof-of-concept example: catserver, a web server that served a simple page with full screen Animated GIFs of cats:

https://www.youtube.com/watch?v=uAThqeOi0yw

Browserify

The first thing I wanted to do is to use Browserify "proper", to write my app in a more modular way. For this I had to fork Justin's original project and modify its package.json so it would let me require() the server instead of tucking its variable in the window globals :-) - sadly I yet have to send him a PR so you will need to be aware of this difference. The dependency in package.json points to my fork for now:


"fxos-web-server": "git+https://github.com/sole/fxos-web-server.git"

Building (with gulp)

My example is composed of two "websites". The first one is the web server app itself which is what is executed in the "server" device. The sources for this are in src.

The second website is what the server will transfer to devices that connect to it, so this actually gets executed in the client devies. This is where the cats are! Its contents are in the www folder.

Both websites are packaged in just one ZIP file and then installed onto the server device.

This build process also involves running Browserify first so I can get from node-style code that uses require() to a JavaScript bundle that runs on Firefox OS. So I'm using gulp to do all that. The tasks are in gulpfile.js.

Web server app

Thanks to Justin's work, this is fairly simple. We create an HTTP server on port 80:


var HTTPServer = require('fxos-web-server');
var server = new HTTPServer(80);

And then we add a listener for when a request is made, so we can respond to it (and serve content to the connected client):


server.addEventListener('request', function(evt) {
      var request = evt.request;
      var response = evt.response;

      //... Decide what to send
});

The "decide what to send" part is a bit like writing nginx or express config files. In this case I wanted to:

  • serve an index.html file if we request a "directory" (i.e. a path that ends with "/")
  • serve static content if we request a file (i.e. the path doesn't end with "/")

Before serving a file we need to tell the client what kind of content we're sending to it. I'm using a very simple "extension to content type" function that determines MIME types based on the extension in the path. E.g. 'html' returns text/html.

Once we know the content type, we set it on the response headers:


response.headers['Content-Type'] = getContentType(fileToSend);

and use Justin's shortcut function sendFile to send a file from our app to the client:


response.sendFile(fileToSend);

With the request handler set up, we can finally start the server!


server.start();

But... how does it even work?!

Welcome to the Hack of The Week!

When you say "sendFile" what the server app does is: it creates an XMLHttpRequest with type = arraybuffer to load the raw contents of the resource. When the XMLHttpRequest emits the load event, the server takes the loaded data and sends it to the client. That's it!

Naive! Simple! It works! (for simple cases)

Ways that this could be improved - AKA "wanna make this better?! this is your chance!"

As I mentioned above, right now this is very naive and assumes that the files will exist. If they don't, well, horrible things will happen. Or you will get a 404 error. I haven't tried it myself. I'm not sure. I'd say there is no error handling (yet).

The extension to content type function could be made into a module, and probably extended to know about more file types. It probably exists already, somewhere in npmlandia.

Another idea I had is that instead of loading the entire resource in memory and then flush it down the pipe as sendFile does, we could use progress events on the XMLHttpRequest and feed it to the client as we load it--so that the server device won't run out of memory. I don't know how we could find the length of the resource first, perhaps a HEAD request could work!

And finally we could try to serve each request in a worker, so that the server doesn't block when responding to a large request. Am I going too far? I don't even know if the TCP sockets work with workers, or if there are issues with that, or who knows!? This is unexplored territory, welcome to Uncertainty Land! :-D

Even extremer ways to get very... "creative"

What if you wrote a PHP parser that runs in JavaScript and then parsed .php files instead of just returning their contents as text/html?

I'm only half kidding, but you could maybe execute JS templates on the server. Forget security! You trust the content, right? ;-)

Another thing you could do is take advantage of the fact that the server is also a browser. So you can do browsersy things such as using Canvas to generate images, instead of having to load libraries that simulate canvas in node. Or you could synthesise web audio stuff on demand--maybe you could use an OfflineAudioWorker for extra non-blocking goodness! Or, if you want to go towards a relatively more boring direction, you could do DOM / text handling on a server that can deal with that kind of stuff natively.

With all the new platforms in which we can run Firefox OS, there are so many things we can do! Phone servers might be limited by battery, but a Raspberry PI running Firefox OS and connected to a power source can be an interesting platform with which to experiment with this kind of easy-to-write web servers.

But I saw NFC mentioned in the video!

Indeed! But I will cover that in another post, so we keep this one focused on the HTTP server :-)

Happy www serving!