Utrecht javascript meetup summaries¶

WebRTC datachannel - Roland van Laar¶

Roland van Laar talks about web applications for education and webrtc data channels.

Webrtc is p2p (peer to peer) for browsers. You can use it for audio, video. Datachannel is a bit like p2p websockets.

Why did he wanted to use it? Well, he writes educational software. In elementary schools in the Netherlands, that often means a teacher and a digiboard. He showed a demo with a website that showed a six-figure code that the teacher then had to type in on his accompagnying phone app. After thus connecting the webbrowser to the phone, he could then steer the webbrowser from the phone. Advancing sheets, and so.

The advantage about webrtc and p2p: it is a direct connection between the phone and the browser, without being dependent on the ofttimes-flaky school’s internet connection.

How do you build up a connection? The one that starts creates an RTCPeerConnection and creates a “session offer”. The one that wants to connect can create a reply, accepting the offer, and send it back. The initial communication has to happen over another type of connection as you haven’t, well, set up the p2p connection yet :-) REST and web sockets are often used for this.

He wrote an alternative, using the local webstorage (localStorageWebRTC). This way, with javascript you can create the “session offer” and store its data locally in the browser’s localstorage.

It is fun. If you want to experiment, look at bistri. For instance http://blog.bistri.com/webrtc-demo. They have samples you can use.

A big problem with webrtc is that it provides almost no feedback about what succeeds or not. So if it doesn’t work, you’re out of luck. If it works, it works…

In the end it turned out to be too much pain to get/keep everything working. The current solution uses websockets.

Distributed Data Protocol (DDP) / Meteor - Peter Peerdeman¶

Peter Peerdeman works at https://lifely.nl/ .

Real time websites are fun. Like http://casperflights.com/unified/?location=eham for live airplane flight tracking.

According to its website, Meteor’s distributed data protocol (DDP) is a simple protocol for fetching structured data from a server, and receiving live updates when that data changes. DDP is like “REST for websockets”.

Real-time functionality in websites is going to be the default. We are going to need to connect to live firehoses like twitter. DDP is a way to share between applications. It has no http, no REST and no request/response cycle. It is pub/sub and remote procedure calls. Basically a bi-directional json.

He showed a live demo with http://endpoint15.meteor.com/, everybody in the audience was happily dragging photos (avatars of the attendees) around on the map. No XHR requests visible in the chrome dev tools, but there was a lot of content moving over a websocket connection.

The DDP spec consists of four parts:

• Connections. You can build up connections and ping each other (and get a “pong” back).

• Managing data. The client can subscribe to data and the server can call back with “added” and “ready” meassages. Similar “changed” and “removed”. You can also unsubscribe. of course.

• Remote procedure calls. You can call a method on the server and get a reply back (well, a “I heard you” message, followed by bits of content and at the end a “ready” message).

• Errors. Errors are passed in a specific json format.

He then showed the demo’s code. One code base, with some explicit if/else parts with Meteor.isClient statements. So: one short 77-line (!) javascript file that runs both on the server and on the client!

(He mentioned https://api.import.io/ as that helped him grab the attendees’ avatars from the meetup page).

What if you cannot use Meteor? Well, it is just a protocol. It is not tied to Meteor. He illustrated that with a second DDP demo build with Node.js on the server and a separate relative normal javascript file on the client.

When to use DDP? You could use it for full stack real-time web applications (if you dare). You can also create realtime functionality as an addition to an existing app. Also nice: the “Internet of Things”: lots of possibilities there!

Can it scale? Well, it is limited to the max connections your box can sustain. If you do loadbalancing, you need “session affinity”. There’s simple autoscaling if you use certain hosted solutions.

See also https://github.com/peterpeerdeman/ddp-the-real-time-api-for-web-applications/ for the code examples.

His closing comment: push the web forward! And give DDP a try. Use DDP instead of yet-another-ad-hoc-message-protocol.