This week we’re joined by long-time web developer Matt Patterson. Earlier this year Matt wrote an evocative article for A List Apart called The Future of Web Software Is HTML-over-WebSockets. In this episode Matt sits down with Jerod to discuss, in-detail, why he believes the future of the web is server-rendered (again) and how Ruby on Rails is well positioned to bring that future to us today.
The dual approach of marrying a Single Page App with an API service has left many dev teams mired in endless JSON wrangling and state discrepancy bugs across two layers. This costs dev time, slows release cycles, and saps the bandwidth for innovation.
What’s old is new again (with a twist):
I won’t spoil the ending where Matt places his bet on the best toolkit to accomplish this, but let’s just say you’ve probably heard of it. Whoops!
Sometimes we need information from our servers instantaneously. For this sort of use case our usual AJAX request/response doesn’t cut it. Instead, we need a push-based method like WebSockets, Long Polling, Server-Sent Events (SSE) and - more recently - HTTP2 push. In this article, we compare two methods for implementing realtime - WebSockets and Server-Sent Events, with information on which to use and when.
This is a nice, reasoned comparison of the two technologies: advantages, stumbling blocks, open source resources, etc.
The WebSocket Inspector is part of the existing Network panel UI in DevTools. It’s already possible to filter the content for opened WS connections in this panel, but till now there was no chance to see the actual data transferred through WS frames.
inlets combines a reverse proxy and websocket tunnels to expose your internal and development endpoints to the public Internet via an exit-node. An exit-node may be a 5-10 USD VPS or any other computer with an IPv4 IP address.
You may be wondering why this project needs to exist, since many like it have come before. The author addresses that right up front:
Similar tools such as ngrok or Argo Tunnel from Cloudflare are closed-source, have limits built-in, can work out expensive and have limited support for arm/arm64. Ngrok is also often banned by corporate firewall policies meaning it can be unusable. Other open-source tunnel tools are designed to only set up a static tunnel. inlets aims to dynamically bind and discover your local services to DNS entries with automated TLS certificates to a public IP address over its websocket tunnel.
This is a nice, deep primer on WebSockets. It includes some web history, describes WebSockets in detail, and catalogs available libraries you can use to get started with them. Here’s the intro to the topic:
In a nutshell, WebSockets are a thin transport layer built on top of a device’s TCP/IP stack. The intent is to provide what is essentially an as-close-to-raw-as-possible TCP communication layer to web application developers while adding a few abstractions to eliminate certain friction that would otherwise exist concerting the way the web works.
Instead, imagine a simple and slim build server tool that is maintained by the Ruby community itself (just like Gemcutter is, or many other infrastructure/tool-level projects are) in order to support all the open-source Ruby projects/gems we’re using every day.
Instead of just imagining, Sven and others have been working toward that vision with Travis, an extremely alpha Rails project. Travis is a single-page application built in Rails and uses Backbone.js as a client-side MVC frontend.
How it works
By configuring a post-receive URL in your GitHub project settings, GitHub will ping Travis when new git commits are received. Travis will then schedule a build in Resque, a Redis queue. Travis then uses Websockets courtesy of PusherApp to update registered browsers on build status as it runs in the background.
Take a look at some of the projects getting built over at travis-ci.org, the project’s new home page or checkout Sven’s quick tour of Travis in this screencast:
Currently, the hosted edition of Travis is open to anyone with a GitHub account. Just sign in with GitHub. Once you’re in, grab your Travis build token and configure a post-receive URL in your GitHub project’s Service Hooks page:
$ cp config/resque.god.example config/resque.god
$ god -c config/resque.god
How you can help
Travis is in EARLY ALPHA. Sven and gang are looking for folks to help test, log issues, and submit patches. If you want to join the community, join the Google Group or hang out in #travis on IRC.
Sven and team would like to offer a special thanks to Pusher App for donating a Big Boy account for the project. If you’d like to pitch in with the compute side of the project, (we’re looking at you Heroku or Linode), please ping Sven.
As new technologies are delivering on the promise of the Real Time Web, it’s becoming apparent that the revolution will be streamed. Malte Ubl seems to agree, creating Streamie, your very own real-time Twitter stream powered by Node.js and Websockets.