WebSocket

back to index

description: computer network protocol

38 results

Realtime Web Apps: HTML5 WebSocket, Pusher, and the Web’s Next Big Thing

by Jason Lengstorf and Phil Leggetter  · 20 Feb 2013

user input. The data is delivered over a single, previously-opened connection. —alex russell there have even been arguments that newer technologies such as html5 Websockets are part of the Comet paradigm and not a replacement for it. however, alex russell (who coined the term) has now confirmed that we should

about old browsers, we can all get on board with “Web Sockets” and the need for any particular umbrella goes away. —Alex Russell The Solution: WebSockets No doubt you’ve heard people talking about HTML5 and all its neat new features. Two of these new features directly apply to realtime web

not have shown up on your radar except as a buzzword in articles talking about all the great new features of HTML5. The reason why WebSockets are so exciting is that they offer a standardized way of achieving what we’ve been trying to do through Comet hacks for years. It

multiple HTTP connections (e.g. using XMLHttpRequest or <iframe>s and long polling).16 One of the most beneficial implications of widespread WebSocket support is in scalability: because WebSockets use a single TCP connection for communication between the server and client instead of multiple, separate HTTP requests, the overhead is dramatically reduced

. The WebSocket Protocol Because full-duplex communication cannot be achieved using HTTP, WebSocket actually defines a whole new protocol, or method of connecting to a server from a client. This is accomplished by

by sending the following headers:17 GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 If the request is successful, the server will return headers that look like these: HTTP/1.1

. We’re also going to be waiting for some parts of the Internet infrastructure to catch up. For instance, some proxies and firewalls block legitimate WebSocket connections. This doesn’t mean we can’t start using them in our applications, however. Why Bother Learning about Realtime Web Technologies? You might be

12 Chapter 1 ■ What Is Realtime? Using Realtime Web Technologies in Your Apps Now Although you may not be able to start relying entirely on WebSocket technology for your new web app, there are a growing number of companies and projects aiming to give you access to realtime web functionality today

. Their approaches vary from using (gasp!) Flash19, which has actually had socket support for years, as a fallback when WebSockets are not natively available to focusing on the HTTP-based solutions we mentioned earlier. Some of the options include Socket.io,20 Faye,21 SignalR

to understand. Nearly every website and web application on the Internet uses some form of HTML to present its data, and ours is no different. • WebSockets to allow realtime interactions between the presenter and the attendees: We’ll go into more detail on this later in the chapter. • Cleaner, easier syntax

to push data to the client rather than requiring the client to constantly ask for new data. let’s have a look at the native Websocket apI to get an idea of how it can be used. Create an htMl file with the following content. this file contains Javascript that connects

to a Websocket echo test service. this means that you can test connecting, sending, and receiving messages. <!doctype html> <html lang="en"> <head> <meta charset="utf-8" /> <title

>Trying out the WebSocket API 02-06</title> </head> <body> <script> var ws = new WebSocket( 'ws://echo.websocket.org' ); ws.onopen = function() { console.log( 'connected' ); console.log( '> hello' ); ws.send( 'hello' ); }; ws.onmessage = function( ev ) { console.

onclose = function() { console.log( 'closed' ); }; ws.onerror = function() { console.log( 'error' ); }; </script> </body> </html> If you open up this page in a browser that supports Websocket and open up the browser’s Javascript console, you’ll see the following: connected > hello < hello The connected message is displayed when

the onopen function handler has been called. The code then logs > hello to indicate it’s going to send hello over the WebSocket connection to the server using the WebSocket send function. Finally, when the server echoes back the message, the onmessage function handler is called, and < hello is logged to

the rest of us, there are a number of services out there that have overcome these hurdles and created APIs that start by checking for WebSocket support; then regressively check for the next-best solution until they find one that works. The result is powerful realtime functionality without any of the

API, which can make it much easier to use than simply dealing with generic messages, as would be the case if we used the native WebSocket API. Finally, because Pusher is a hosted service, it will handle maintaining the persistent connections over which data will be delivered and can deal with

in the UK. When they saw the need to synchronize data between their team members, they built a small tool to utilize the new HTML5 WebSocket API. Once they realized how easy it was to create realtime applications using their infrastructure, they saw an opportunity that went beyond internal management tools

the client. We’ll dig deeper into the functionality that’s available as we work our way through this chapter. Other Client Libraries Although the WebSocket specification now falls under the HTML5 umbrella, it’s important to remember that it’s a specification of a protocol. What this means is that

any technology that can make a TCP connection can also make a WebSocket connection. Pusher takes advantage of this and also offers client libraries in a number of other technologies, including Objective-C for iOS development, Java

align left while the text after the tab aligns right. Now add the rest of the footer text: Part of Realtime Web Apps: With HTML5 WebSocket, PHP, and jQuery. Get the Book | Source Code (on GitHub). 3. For the links Get the Book and Source Code (on GitHub), select each

. </p><!--/.tagline--> </header> <footer> <ul> <li class="copyright"> &copy; 2013 Jason Lengstorf &amp; Phil Leggetter </li><!--/.copyright--> <li> Part of Realtime Web Apps: HTML5 <em>Websockets, Pusher, and the Web&rsquo;s Next Big Thing</em>. </li> <li> <a href="http://amzn.to/XKcBbG">Get the Book</a> | <a href="http

--> </header> <section>   </section> <footer> <ul> <li class="copyright"> &copy; 2013 Jason Lengstorf &amp; Phil Leggetter </li><!--/.copyright--> <li> Part of Realtime Web Apps: HTML5 <em>Websockets, Pusher, and the Web&rsquo;s Next Big Thing</em>. </li> <li> <a href="http://amzn.to/XKcBbG">Get the Book</a> | <a href="http

question." type="submit" /> </form> </li><!--/#question-1--> <li id="question-2" data-count="14"> <p> Does this work on browsers that don't support the WebSockets API? </p> <form class="vote"> <input value="I also have this question." type="submit" /> </form> </li><!--/#question-2--> </ul><!--/#questions--> With the markup in place

" data-count="14"> <form class="answer"> <input type="submit" value="Answer this question." /> </form> <p> Does this work on browsers that don't support the WebSockets API? </p> </li> </ul><!--/#questions--> </section> View this file in your browser; it needs a little tweaking, but it is close (see Figure 7-25

Chapter 7: <footer> <ul> <li class="copyright"> &copy; 2013 Jason Lengstorf &amp; Phil Leggetter </li><!--/.copyright--> <li> Part of Realtime Web Apps: With HTML5 <em>WebSocket, PHP, and jQuery</em>. </li> 4 http://www.php.net/manual/en/intro.pdo.php 179 Chapter 8 ■ Building the Back End: Part 1 <li

119 CSS code, 115–116 font styling rules, 117 header and footer, 119 layout rules, 118 working principle, 17 HTML5 WebSocket Technology and Pusher application nervous system, 31 need for, 31 WebSocket API, 30–31 working principle, 32 HTTP, real-time hacks, 5 long-polling, 7 problems with, 8 streaming, 8 nI

37 REST API, 36 scalability, 35 send events, 43 server libraries, 36 sign-up, 37 trigger and publish, 37 trigger method, 49 uses of, 35 webSocket, 36 nR Realtime AJAX, 5 definition of, 5 Google Docs and Google Analytics, 12 HTTP hacks, 5 long-polling, 7 problems with, 8 streaming, 8

polling, 5 social media, 3–4 terminology, 9 web sites, 4 websocket protocol, 10 Realtime implementation back end answer event, 249 console, room events, 247 event creation, 245 pusher debug console, 246 question markup, ask event, 248

?�������������������������������������������������������������������������������������������������� 5 AJAX���������������������������������������������������������������������������������������������������������������������������������������������������������������������� 5 Polling�������������������������������������������������������������������������������������������������������������������������������������������������������������������� 5 HTTP Long-Polling������������������������������������������������������������������������������������������������������������������������������������������������� 7 HTTP Streaming����������������������������������������������������������������������������������������������������������������������������������������������������� 8 Additional Problems with HTTP-based Solutions in Web Browsers����������������������������������������������������������������������� 8 The Solution: WebSockets�����������������������������������������������������������������������������������������������������������10 The WebSocket Protocol�������������������������������������������������������������������������������������������������������������������������������������� 11 Why Bother Learning about Realtime Web Technologies?����������������������������������������������������������12 Using Realtime Web Technologies in Your Apps Now������������������������������������������������������������������13 Summary�������������������������������������������������������������������������������������������������������������������������������������13 ■■Chapter 2: The

Does That Mean Development-Wise?��������������������������������������������������������������������������������������������������������� 15 Choosing Our Tools����������������������������������������������������������������������������������������������������������������������16 vii ■ Contents HTML5 ����������������������������������������������������������������������������������������������������������������������������������������������������������������� 16 CSS3 �������������������������������������������������������������������������������������������������������������������������������������������������������������������� 18 JavaScript and jQuery ����������������������������������������������������������������������������������������������������������������������������������������� 22 PHP ���������������������������������������������������������������������������������������������������������������������������������������������������������������������� 25 MySQL ����������������������������������������������������������������������������������������������������������������������������������������������������������������� 27 HTML5 WebSocket Technology and Pusher ��������������������������������������������������������������������������������������������������������� 30 OAuth ������������������������������������������������������������������������������������������������������������������������������������������������������������������� 32 Summary �������������������������������������������������������������������������������������������������������������������������������������33 ■ Chapter 3: Pusher ������������������������������������������������������������������������������������������������������������35 A Brief History of Pusher �������������������������������������������������������������������������������������������������������������35 Why Use Pusher? ������������������������������������������������������������������������������������������������������������������������35 Scalability ������������������������������������������������������������������������������������������������������������������������������������������������������������ 35

WebSocket, Fallback Support, and Auto-Reconnect�������������������������������������������������������������������������������������������� 36 Other Client Libraries ������������������������������������������������������������������������������������������������������������������������������������������� 36 REST API �������������������������������������������������������������������������������������������������������������������������������������������������������������� 36 Server Libraries ��������������������������������������������������������������������������������������������������������������������������������������������������� 36 Developer Tools ��������������������������������������������������������������������������������������������������������������������������������������������������� 36 Documentation ���������������������������������������������������������������������������������������������������������������������������������������������������� 36 Pusher Terminology ���������������������������������������������������������������������������������������������������������������������37 Getting

Professional Node.js: Building Javascript Based Scalable Software

by Pedro Teixeira  · 30 Sep 2012  · 325pp  · 85,599 words

Setting Up Middleware in Your Application Routing Requests Summary Chapter 22: Making Universal Real-Time Web Applications Using Socket.io Understanding How WebSockets Work Using Socket.IO to Build WebSocket Applications Summary Part VI: Connecting to Databases Chapter 23: Connecting to MYSQL Using node-mysql Using a Library to Connect to and

Real-Time Web Applications Using Socket.IO WHAT’S IN THIS CHAPTER? Understanding the history of HTTP in relation to real-time applications Understanding how WebSockets enable real-time applications on the web Using Socket.IO to write real-time applications for Node.js Writing a web-based real-time chat

long-running request responses, and keeping the connection open usually resulted in inefficient load behavior on the server. Today, the situation is much better. The WebSocket protocol was developed (and recently standardized) to overcome the shortcomings of HTTP in relation to real-time applications, which now enables HTTP clients and browsers

web applications can use only web technologies, without the need to for external technologies like Java Applets, Flash, or ActiveX. UNDERSTANDING HOW WEBSOCKETS WORK At its core, a WebSocket connection is just a conventional TCP connection between an HTTP server and an HTTP client. It’s established using a handshake protocol, which

the server, asking it to turn the connection of this request into a WebSockets connection: GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Although this starts out as a regular HTTP connection, the

client asks to “upgrade” this connection to a WebSocket connection. If the server supports the WebSocket protocol, it answers like this

: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK

+xOo= Sec-WebSocket-Protocol: chat This marks the end of the handshake, and the connection switches

and server can send messages to one another at any time without having to wait for one another. USING SOCKET.IO TO BUILD WEBSOCKET APPLICATIONS Although implementing your own WebSocket server for Node.js is possible, it’s not necessary. Many low-level details need to be taken care of before you

it, which makes using a library a lot more practical. The de facto standard library for building WebSocket Node.js applications is Socket.IO. Not only is it a wrapper library that makes building WebSocket servers very convenient, it also provides transparent fallback mechanisms like long polling for clients that don’t

support the WebSocket protocol. Furthermore, it ships with a client-side library that provides a convenient API for developing the browser part of the application. Using Socket.IO,

you never need to grapple with the low-level implementation details of a WebSocket server or client. You get a clean and expressive API on both sides, which allows writing real-time applications with ease. Installing and Running Socket

NPM module and can therefore be installed with the following: $ npm install socket.io After you’ve installed it, you can implement a very basic WebSocket server, as shown in Listing 22-1. LISTING 22-1: Setting up a Socket.IO server. var io = require('socket.io').listen(4000); io.sockets

, the first step is to bind to a TCP port, 4000 in this case. As soon as the server is running, it listens to incoming WebSocket connections. The connection event is triggered as soon as a new client connects. The server then listens for incoming messages on this connection, logging the

of any message it receives. NOTE As you can see, Socket.IO provides a message-oriented communication mechanism. This is an improvement over the underlying WebSockets protocol, which doesn’t provide message framing. You can also see that Socket.IO does not distinguish between a client that is connected using

WebSockets or any other type of mechanism: It provides a unified API that abstracts away those implementation details. The event name my event is arbitrary – it’

the client gives the messages it sends, and it is used to distinguish among different types of messages within an application. On the client, a WebSocket connection is created by connecting to the server. This socket is then used to emit (or send) a message with the label my event to

(200); res.end(data); } ); } io.sockets.on('connection', function (socket) { socket.on('my event', function(content) { console.log(content); }); }); What happens here is that the WebSocket server links into the HTTP server and listens to certain requests. Whenever a client requests anything below /socket.io, Socket.IO handles these requests, returning

the socket.io.js script or setting up a WebSocket connection. Any other request receives the index.html file as a response. Now you can point your browser to http://localhost:4000/ – the string "Hello

; } }; When everything is put together, index.html looks Listing 22-5. LISTING 22-5: A simple Socket.IO chat client. <html> <head> <title>Node.js WebSocket chat</title> <style type="text/css"> #input { width: 200px; } #messages { position: fixed; top: 40px; bottom: 8px; left: 8px; right: 8px; border: 1px solid #EEEEEE; padding

('serverMessage', 'User ' + username + ' logged in'); }); }); socket.emit('login'); }); LISTING 22-7: A Socket.IO chat client that supports user login. <html> <head> <title>Node.js WebSocket chat</title> <style type="text/css"> #input { width: 200px; } #messages { position: fixed; top: 40px; bottom: 8px; left: 8px; right: 8px; border: 1px solid #EEEEEE; padding

the client code that allows that. LISTING 22-9: A Socket.IO chat client that accepts the /j <room> command. <html> <head> <title>Node.js WebSocket chat</title> <style type="text/css"> #input { width: 200px; } #messages { position: fixed; top: 40px; bottom: 8px; left: 8px; right: 8px; border: 1px solid #EEEEEE; padding

running a load balancer in front of a set of Node.js processes that run Socket.IO servers, you need to use one that supports WebSockets. If you want to run a Node-based Socket.IO server, I recommend looking at the node-http-proxy module, which is very malleable and

front-end code. LISTING 24-4: A new version of the Socket.IO-based chat client that formats the messages. <html> <head> <title>Node.js WebSocket chat</title> <style type="text/css"> #input { width: 200px; } #messages { position: fixed; top: 40px; bottom: 8px; left: 8px; right: 8px; border: 1px solid #EEEEEE; padding

modified front-end code. LISTING 24-6: A new version of the Socket.IO-based chat client that presents avatars. <html> <head> <title>Node.js WebSocket chat</title> <style type="text/css"> #input { width: 200px; } #messages { position: fixed; top: 40px; bottom: 50px; left: 8px; right: 8px; border: 1px solid #EEEEEE; padding

Introduction to Tornado

by Michael Dory, Adam Parrish and Brendan Berg  · 29 Sep 2011  · 136pp  · 20,501 words

user-to-user chat or message notifications, where only a few users’ connections will close at a time, this is less of an issue. WebSockets with Tornado WebSockets are a new protocol for client-server communication proposed in the HTML 5 spec. The protocol is still a draft, and only the most

, it’s prudent to adhere to the pragmatic strategy of relying on new features when available and falling back on older technology when necessary.) The WebSocket protocol provides bidirectional communication over a persistent connection between a client and server. The protocol itself uses a new ws:// URL scheme, but is implemented

HTML 5 spec not only describes the communication protocol itself, but also the browser APIs that are required to write client-side code that use WebSockets. Since WebSocket support is already supported in some of the latest browsers and since Tornado helpfully provides a module for it, it’s worth seeing how

to implement applications that use WebSockets. Tornado’s WebSocket Module Tornado provides a WebSocketHandler class as part of the websocket module. The class provides hooks for WebSocket events and methods to communicate with the connected client. The open method is called when a

new WebSocket connection is opened, and the on_message and on_close methods are called when the connection receives a new message or is closed by the

method to close the connection. Let’s look at a simple handler that repeats the messages it receives back to the client. class EchoHandler(tornado.websocket.WebSocketHandler): def on_open(self): self.write_message('connected!') def on_message(self, message): self.write_message(message) As you can see in our EchoHandler

is to it! Let’s take a look at a complete example to see how easy this protocol is to implement. Example: Live Inventory with WebSockets In this section, we will see how easy it is to update the HTTP long polling example we saw previously to use

WebSockets. Keep in mind, however, that WebSockets are a new standard and are only supported by the very latest browser versions. The specific WebSocket protocol versions that Tornado supports are only available in Firefox versions 6.0 and

to the ShoppingCart and StatusHandler classes. Example 5-7 should look familiar. Example 5-7. Web Sockets: shopping_cart.py import tornado.web import tornado.websocket import tornado.httpserver import tornado.ioloop import tornado.options from uuid import uuid4 class ShoppingCart(object): totalInventory = 10 callbacks = [] carts = {} def register(self, callback): self

) return if action == 'add': self.application.shoppingCart.moveItemToCart(session) elif action == 'remove': self.application.shoppingCart.removeItemFromCart(session) else: self.set_status(400) class StatusHandler(tornado.websocket.WebSocketHandler): def open(self): self.application.shoppingCart.register(self.callback) def on_close(self): self.application.shoppingCart.unregister(self.callback) def on_message(self, message

() Other than an additional import statement, we need only to change the ShoppingCart and StatusHandler classes. The first thing to notice is that the tornado.websocket module is required in order to get the WebSocketHandler functionality. In the ShoppingCart class, we need to make a slight change to the way we

notify callbacks. Since WebSockets stay open after a message is sent, we don’t need to remove callbacks from the internal list as they are notified. We just iterate

.callbacks: callback(self.getInventoryCount()) The other change is to add the unregister method. The StatusHandler will call this method to remove a callback when a WebSocket connection closes. def unregister(self, callback): self.callbacks.remove(callback) The bulk of changes are in the StatusHandler class, which now inherits from tornado

.websocket.WebSocketHandler. Instead of implementing handler functions for each of the HTTP methods, WebSocket handlers implement the open and on_message methods, which are called when a connection is opened and when a

is received over the connection, respectively. Additionally, the on_close method is called when a connection is closed by the remote host. class StatusHandler(tornado.websocket.WebSocketHandler): def open(self): self.application.shoppingCart.register(self.callback) def on_close(self): self.application.shoppingCart.unregister(self.callback) def on_message(self, message

connection is closed. Since we’re still using the HTTP API calls in the CartHandler class, we don’t listen for new messages on the WebSocket connection, so the on_message implementation is empty. (We override the default implementation of on_message to prevent Tornado from raising a NotImplementedError if we

happen to receive a message.) Finally, the callback method writes the message contents to the WebSocket connection when the inventory changes. The JavaScript code in this version is virtually identical. We just need to change the requestInventory function. Instead of making

an AJAX request for the long polling resource, we use the HTML 5 WebSocket API. See Example 5-8. Example 5-8. Web Sockets: The new requestInventory function from inventory.js function requestInventory() { var host = 'ws://localhost:8000/cart

/status'; var websocket = new WebSocket(host); websocket.onopen = function (evt) { }; websocket.onmessage = function(evt) { $('#count').html($.parseJSON(evt.data)['inventoryCount']); }; websocket.onerror = function (evt) { }; } After creating a new WebSocket connection to the URL ws://localhost:8000/cart/status, we add handler functions for each

dynamically as shoppers add the book to their cart. The difference here is that one persistent WebSocket connection is used instead of re-opening HTTP requests with each long polling update. The Future of WebSockets The WebSocket protocol is still in draft form, and may change as it is finalized. However, since the

face significant changes. As mentioned in the beginning of this section, the major downside to using the WebSocket protocol right now is that only the very latest browsers support it. Despite those caveats, WebSockets are a promising new way to implement bidirectional communication between a browser and server. As the protocol gains

Programming HTML5 Applications

by Zachary Kessin  · 9 May 2011  · 210pp  · 42,271 words

earlier versions of the web sockets standard that are not always compatible. The Web Sockets Interface To use a web socket, start by creating a WebSocket object. As a parameter, pass a web socket URL. Unlike an HTTP URL, a web socket URL will start with ws or wss. The latter

is a secure web socket that will use SSL, similar to HTTPS under Ajax: var socket = new WebSocket("ws://example.com/socket"); Once a socket connection is opened, the socket’s socket.onopen() callback will be called to let the program know that

server that this is a web socket connection and not an HTTP connection. It also includes some handshaking bytes to provide some security. Since the WebSocket protocol uses ports 80 and 443, most proxies and firewalls should deal with it correctly. Web sockets can also specify a different port in the

when it changes. The client will just refresh the element every time the price changes. Example 9-1. Socket client example $(function () { var socket = new WebSocket('ws://localhost/stockprice'); // wait for socket to open socket.onopen = function () { socket.send(JSON.stringify( { ticker: "ibm" })); }; socket.onmessage = function (msg) { var prices = $.parseJSON(msg

use web sockets. In the following example of server code, done in Node.js (see Example 9-2), a server is set up using the websocket-server package, which can be found via NPM or on GitHub. The server waits for a connection on port 8080, and when one comes in

guide to programming Node.js, see Node: Up and Running by Tom Hughes-Croucher (O’Reilly). Example 9-2. Socket server example var ws = require("websocket-server"); var server = ws.createServer(); server.addListener("connection", function (connection) { connection.addListener("message", function (msg) { var tickerSymbol = msg.ticker; tickerUpdate(tickerSymbol, function (price) { var msg

an HTTP GET request but with a few extra headers (see Example 9-3). Example 9-3. Socket headers GET /socket HTTP/1.1 Upgrade: WebSocket Connection: Upgrade Origin: http://www.test.com Host: www.test.com Content-Length: 0 After the connection has been set up, frames of data are

web sockets, as the programmer is given an event-based interface from which a stream of data can be sent to the client. The EventMachine::WebSocket interface closely matches the interface in JavaScript. As in the client, the EventMachine interface has standard event handlers for onopen, onmessage, and onclose, as well

-4 shows a very trivial “hello world” type of web socket interface in Ruby. Example 9-4. Ruby Event Machine web socket handler require 'em-websocket' EventMachine::WebSocket.start(:host => "0.0.0.0", :port => 8080) do |ws| ws.onopen { ws.send "Hello Client!"} ws.onmessage { |msg| ws.send "Pong: #{msg}" } ws

.onclose { puts "WebSocket closed" } end Erlang Yaws Erlang is a pretty rigorously functional language that was developed several decades ago for telephone switches and has found acceptance in

", "You're not a web sockets client! Go away!"}; "WebSocket" -> WebSocketOwner = spawn(fun() -> websocket_owner() end), {websocket, WebSocketOwner, passive} end. websocket_owner() -> receive {ok, WebSocket} -> %% This is how we read messages (plural!!) from websockets on passive mode case yaws_api:websocket_receive(WebSocket) of {error,closed} -> io:format("The websocket got disconnected right from the start. " "This wasn't

supposed to happen!!~n"); {ok, Messages} -> case Messages of [<<"client-connected">>] -> yaws_api:websocket_setopts(WebSocket

, [{active, true}]), echo_server(WebSocket); Other

-> io:format("websocket_owner got: ~p

. Terminating~n", [Other]) end end; _ -> ok end. echo_server(WebSocket

) -> receive {tcp, WebSocket, DataFrame} -> Data = yaws_api:websocket_unframe_data(DataFrame), io:format("Got data from Websocket: ~p~n", [Data]), yaws_api:websocket_send(WebSocket, Data), echo_server(WebSocket); {tcp_closed, WebSocket} -> io:format("Websocket closed. Terminating echo_server...~n"); Any -> io:format("echo_server received msg

:~p~n", [Any]), echo_server(WebSocket) end. get_upgrade_header(#headers{other=L}) -> lists:foldl(fun({http_header,_,K0

Designing Web APIs: Building APIs That Developers Love

by Brenda Jin, Saurabh Sahni and Amir Shevat  · 28 Aug 2018

that allows you to make the changes you want in the future. Over the years, multiple API paradigms have emerged. REST, RPC, GraphQL, WebHooks, and WebSockets are some of the most popu‐ lar standards today. In this chapter, we dive into these different para‐ digms. Request–Response APIs Request–response APIs

about 1.5% of their polling API calls returned new data. To share data about events in real time, there are three common mechanisms: WebHooks, WebSockets, and HTTP Streaming. We dive deeper into each of them in the subsections that follow. WebHooks A WebHook is just a URL that accepts an

time that need to be sent via a single WebHook, it can be noisy. Figure 2-4. Configuring a GitHub WebHook Event-Driven APIs | 21 WebSockets WebSocket is a protocol used to establish a two-way streaming com‐ munication channel over a single Transport Control Protocol (TCP) connection. Although the protocol is

.g., a browser) and a server, it’s sometimes used for serverto-server communication, as well. The WebSocket protocol is supported by major browsers and often used by real-time applications. Slack uses WebSockets to send all kinds of events happening in a workspace to Slack’s clients, includ‐ ing new messages

, emoji reactions added to items, and channel crea‐ tions. Slack also provides a WebSocket-based Real Time Messaging API to developers so that they can receive events from Slack in real time and send messages as users. Similarly, Trello

uses WebSockets to push changes made by other people down from servers to brows‐ ers listening on the appropriate channels, and Blockchain uses its WebSocket API to send real-time notifications about new transac‐ tions and blocks

. WebSockets can enable full-duplex communication (server and cli‐ ent can communicate with each other simultaneously) at a low over

ports. This is an especially important consideration when it comes to enterprise developers. For example, some enterprise developers using Slack APIs prefer to use the WebSocket API over WebHooks because they are able to receive events from the Slack API securely without having to open up an HTTP WebHook endpoint to

the internet where Slack can post messages. WebSockets are great for fast, live streaming data and long-lived connections. However, be wary if you plan to make these available on mobile devices or

keep the connection alive. If the connection dies, the client needs to reinitiate it. There are also issues related to scalability. Developers using Slack’s WebSocket API must establish a connection for each team that uses their app (Figure 2-5). This means that if an app is installed on 10

10,000 connections between Slack servers and the app’s server. 22 | Chapter 2: API Paradigms Figure 2-5. Frames sent over a full-duplex WebSocket connection between Slack and a browser HTTP Streaming With the HTTP request–response APIs, clients send an HTTP request and the server returns an HTTP

options. Table 2-3. Comparison of event-driven APIs What? Example services Pros 24 | WebHooks Event notification via HTTP callback Slack, Stripe, GitHub, Zapier, Google WebSockets Two-way streaming connection over TCP Slack, Trello, Blockchain HTTP Streaming Long-lived connection over HTTP Twitter, Facebook • Easy server-to-server communication • Two-way

HTTP • Uses HTTP protocol • Native browser support • Native browser support • Can bypass firewalls • Can bypass firewalls Chapter 2: API Paradigms Cons When to use? WebHooks WebSockets HTTP Streaming • Do not work across firewalls or in browsers • Need to maintain a persistent connection • Handling failures, retries, security is hard • Not HTTP • Bidirectional

well for certain kinds of use cases. You might need to support multiple paradigms, too. For example, the Slack API sup‐ ports RPC-style APIs, WebSockets, and WebHooks. It’s important for you to understand which solution will work best for your cus‐ tomers, which will help you meet your business

considering a variety of event-driven APIs. Table 5-6 lays out the pros and cons of three common patterns for the MyFiles API: WebHooks, WebSockets, and HTTP Streaming. If you need a refresher on the various types of event-driven APIs, head back to Chapter 2. Table 5-6. Pros

API paradigms for the MyFiles API Paradigm WebHooks Pros MyFiles developers might want to receive an event every time files are added, removed, or changed. WebSockets Can be used by internal clients for UI display. HTTP Streaming Good for pushing data frequently. Cons If files are changing too frequently, we might

be able to receive WebHook requests. Other things we considered There are a number of ways to design event-driven APIs, and we elected WebHooks. WebSockets and long-lived HTTP streaming connections were also considered. In addition to the high-level overview, let’s also write details about the events and

: Zapier, Twitter, GitHub, and Slack. If polling is one of your API scaling problems and you have only REST APIs, you should explore options like WebSockets and Web‐ Hooks. Your developers will not need to poll for changes but can wait for new data to be delivered in real time. A

allowed developers to build apps and bots that could respond in real time to activities in Slack. The API delivered events from Slack over a WebSocket. As time went on, Slack discovered that even though the RTM API was great for its own clients, it provided too much data for developers

, and its members. Originally designed for small teams, this API method would return the full application state, in addition to a session URL for a WebSocket connection. As team sizes grew, this payload became unwieldy and large—up to several megabytes, which was expensive for developers to handle. Even though a

handful of devel‐ opers used the data returned from this method, most developers wanted only to connect to the WebSocket. As a result, Slack intro‐ duced a new API method, rtm.connect, that simply returns an 92 | Chapter 6: Scaling APIs RTM

WebSocket API session URL without returning any other data in the payload. This new method has helped application developers and Slack to overcome some of the

have to return “Hello, world”, but you might have users get to a place where they’ve suc‐ cessfully made one API request, opened a WebSocket connection and received the first event, or received an example POST request from a WebHook. The Getting Started tutorial’s job is to outline the

designing APIs, best practices; designing APIs, practical exercise in) event-driven, 19-25 comparison of different types, 24 HTTP Streaming, 23-24 WebHooks, 19-22 WebSockets, 22-23 request–response comparison of types, 18 GraphQL, 14-18 REST, 10-13 RPC, 13-14 security (see security) uses of, 2 application names

event-driven APIs, 19-25 comparison of different types, 24 HTTP Streaming, 23-24 pros and cons for MyFiles API (example), 74 WebHooks, 19-22 WebSockets, 22-23 events (developer), 194 Events API (Slack), 91 evolving API design, 90-97 adding new API methods, 92 best practices, 97 introducing new data

, 10 indicating redirection for moved/ moving resources, 135 organizing errors into, 54 returning for rate limits, 110 HTTP Streaming, 23-24 comparison with WebHooks and WebSockets, 24 pros and cons for MyFiles eventdriven API (example), 74 HTTPs endpoints (OAuth), 39 human-readable errors, 52 H I hackathons, 194 hackers, 145 hash

granular OAuth scopes, lessons learned from, 34 rate-limiting, lessons learned from, 113 RPC-style web API, 13 translation layer to maintain backward compatibility, 57 WebSocket-based real-time mes‐ saging API, 22 sliding-window counter (ratelimiting), 108 snippets (code), 174 software as a service (SaaS) compa‐ nies, 4 software development

and MINOR changes, 138 process management, 141 vertical scaling, 85 videos creating, 180 online videos and streaming, 196 W WebHooks, 19-22, 90 comparison with WebSockets and HTTP Streaming, 24 considerations for use in MyFiles API (example), 66 MyFiles API Webhooks Spec (example), 74-77 polling vs., 19 pros and cons

and WebHook signatures, 43 thin payloads and API retrieval, 44 verification tokens, 42 supporting, additional complexi‐ ties added by, 20 webinars and online training, 182 WebSockets, 22-23, 90 comparison with WebHooks and HTTP Streaming, 24 pros and cons for MyFiles eventdriven API (example), 74 Y YouTube API, value proposition, 151

Node.js in Action

by Mike Cantelon, Marc Harter, Tj Holowaychuk and Nathan Rajlich  · 27 Jul 2013  · 628pp  · 107,927 words

. Summary Chapter 2. Building a multiroom chat application 2.1. Application overview 2.2. Application requirements and initial setup 2.2.1. Serving HTTP and WebSocket 2.2.2. Creating the application file structure 2.2.3. Specifying dependencies 2.2.4. Installing dependencies 2.3. Serving the application’s HTML

transfer is larger because HTTP headers are sent on every request. Instead of employing a solution reliant on HTTP, this application will prefer WebSocket (http://en.wikipedia.org/wiki/WebSocket), which was designed as a bidirectional lightweight communications protocol to support real-time communication. Since only HTML5-compliant browsers, for the most

part, support WebSocket, the application will leverage the popular Socket.IO library (http://socket.io/), which provides a number of fallbacks, including the use of

Flash, should using WebSocket not be possible. Socket.IO handles fallback functionality transparently, requiring no additional code or configuration. Socket.IO is covered more deeply in chapter 13. Before

preliminary work of setting up the application’s file structure and dependencies, let’s talk more about how Node lets you simultaneously handle HTTP and WebSocket—one of the reasons why it’s such a good choice for real-time applications. 2.2.1. Serving HTTP and

WebSocket Although this application will avoid the use of Ajax for sending and receiving chat messages, it will still use HTTP to deliver the HTML, CSS,

and client-side JavaScript needed to set things up in the user’s browser. Node can easily handle simultaneously serving HTTP and WebSocket using a single TCP/IP port, as figure 2.5 depicts. Node comes with a module that provides HTTP serving functionality. There are a number

to build web applications in chapter 8. In this chapter’s application, however, we’ll stick to the basics. Figure 2.5. Handling HTTP and WebSocket within a single application Now that you have a rough idea of the core technologies the application will use, let’s start fleshing it out

first one, serving static files, and now we’ll tackle the second—handling communication between the browser and server. Modern browsers are capable of using WebSocket to handle communication between the browser and the server. (See the Socket.IO browser support page for details on supported browsers: http://socket.io/#browser

-support.) Socket.IO provides a layer of abstraction over WebSocket and other transports for both Node and client-side JavaScript. Socket.IO will fall back transparently to other WebSocket alternatives if WebSocket isn’t implemented in a web browser while keeping the same API. In this section

. This is a fantastic feature for any application expecting large uploads, and it’s a task that Node is well suited for. By using the WebSocket protocol, for instance, or a real-time module like Socket.IO, it would be possible in just a few lines of code. We’ll leave

web applications using a bidirectional communication channel between the server and client. At its simplest, Socket.IO has an API very similar to the WebSocket API (http://www.websocket.org), but has built-in fallbacks for older browsers where such features did not yet exist. Socket.IO also provides convenient APIs for

, short-lived requests to the server, and the server has no real notion of connected or disconnected users. This limitation prompted the standardization of the WebSocket protocol, which specifies a way for browsers to maintain a full-duplex connection to the server, allowing both ends to send and receive data simultaneously

. WebSocket APIs allow for a whole new breed of web applications utilizing real-time communication between the client and server. The problem with the WebSocket protocol is that it’s not yet finalized, and although some browsers have begun

shipping with WebSocket, there are still a lot of older versions out there, especially of Internet Explorer. Socket.IO solves

this problem by utilizing WebSocket when it’s available in the browser, and falling back to other browser-specific

tricks to simulate the behavior that WebSocket provides, even in older browsers. In this section, you’ll build two sample applications using Socket.IO: A minimal Socket.IO application that pushes the

of Socket.IO As you know, HTTP was never originally intended for any kind of real-time communication. But with advances in browser technologies, like WebSocket, and with modules like Socket.IO, this limitation has been lifted, opening a big door for all kinds of new applications that were never before

) W warn function watch function, 2nd watchers command watchFile function, 2nd watching file/folder changes triggering page reload for using fs module projects on GitHub WebSocket API, 2nd wget package when statements while statements Windows. See Microsoft Windows. writable WritableStream write() function, 2nd, 3rd, 4th, 5th writeFile() function writeInt16LE function writeInt32BE

’s chat name Figure 2.3. Changing rooms Figure 2.4. The results of changing to a new room Figure 2.5. Handling HTTP and WebSocket within a single application Figure 2.6. The skeletal project directory for the chat application Figure 2.7. When npm is used to install dependencies

Principles of Web API Design: Delivering Value with APIs and Microservices

by James Higginbotham  · 20 Dec 2021  · 283pp  · 78,705 words

to inform the consumer when something has changed. There are a variety of API styles that support asynchronous APIs: webhooks, Server-Sent Events (SSE), and WebSockets are the most common. Server Notification Using Webhooks Webhooks allow API servers to publish notifications to other interested servers when an event has occurred. Unlike

support SSE. Refer to Mozilla’s list of compatible browsers for more information ■ Bi-directional communication between client and server is required. In this case, WebSockets may be a better option as SSE is server push only The W3C SSE specification is easy to read and offers additional specifications and examples

. Bi-Directional Notification via WebSockets WebSockets support the tunneling of a full-duplex protocol, called a sub-protocol, within a single TCP connection that is initiated using HTTP. Because they are

becomes possible between API clients and servers. Clients are able to push requests to the server over a WebSocket, all while the server is able to push events and responses back to the client. WebSockets is a standardized protocol maintained by the Internet Engineering Task Force as RFC 6455. Most browsers support

WebSockets, making it easy to use for browser-to-server, server-to-browser, and server-to-server scenarios. Since WebSockets are tunneled through HTTP connections, they can also overcome proxy restrictions found in some organizations. An

important factor to keep in mind is that WebSockets don't behave like HTTP, even though it uses HTTP to initiate the connection. Instead, a sub-protocol must be selected. There are many subprotocols

officially registered with IANA. WebSockets support both text and binary format sub-protocols. Figure 9.9 shows an example WebSocket interaction using a plain text sub-protocol. Figure 9.9 An example interaction between an API client and

server using WebSockets and a plain text subprotocol to create a chat application. WebSockets are more complex to implement but supports bi-directional communication. This means that they allow clients to send data to the

from the server using the same connection. While SSE is easier to implement, clients are not able to send requests on the same connection making WebSockets a better option when full duplex communication is necessary. Keep this in mind when choosing an async API style. gRPC Streaming TCP protocol is optimized

style of HTTP/1.1. gRPC takes advantage of HTTP/2’s bi-directional communication support, removing the need to separately support request/response alongside WebSockets, SSE, or other push-based approaches on top of HTTP/1.1. Since gRPC supports bi-directional communication, async APIs can be designed and integrated

The three gRPC-based streaming options available: client-to-server, server-to-client, and bi-directional. Like WebSockets, gRPC can send and receive messages and events across a single, full-duplex connection. Unlike WebSockets, there are no subprotocol decisions to be made and supported as gRPC uses Protocol Buffers by default. However

bi-directional communication between client and server. Use SSE when there is a need for the server-push of events that follows RESTful API design. ■ WebSockets: WebSockets are more complex to implement due to the need to support one or more sub-protocols, but they support bi-directional communication. They are also

advantage of HTTP/2, so all infrastructure and subscribers must be able to support this newer protocol to take full advantage of gRPC streaming. Like WebSockets, it offers bi-directional communication. gRPC isn't supported fully by browsers, so gRPC streaming is best suited for service-to-service communication or for

must consider how new API styles will be evaluated, approved, and supported as they gain popularity. API programs must consider async APIs, such as Webhooks, WebSockets, SSE, data streaming, and internal messaging as part of the API portfolio. Like synchronous APIs, the design of async APIs must be governed and managed

Vue.js 2 Cookbook

by Andrea Passaglia  · 27 Apr 2017  · 550pp  · 84,515 words

it works... Advanced Vue.js – Directives, Plugins, and Render Functions Introduction Creating a new directive Getting ready How to do it... How it works… Using WebSockets in Vue Getting ready How to do it... How it works... Writing a plugin for Vue Getting ready How to do it... How it works

component(s). Advanced Vue.js – Directives, Plugins, and Render Functions In this chapter, we will talk about the following topics: Creating a new directive Using WebSockets in Vue Writing a plugin for Vue Rendering a simple component manually Rendering a component with children Using JSX to render a component Creating a

vnode: the Vue internal representation of this element We used the el parameter to edit the appearance of our element, manipulating it directly. Using WebSockets in Vue WebSockets are a new technology that enables two-way communication between the user and the server where the app is hosted. Before this technology, only

could initiate a request and, thus, a connection. If some update on the page was expected, the browser had to continuously poll the server. With WebSockets, this is no longer necessary; after the connection is established, the server can send updates only when there is a need. Getting ready You don

't need any preparation for this recipe, just the basics of Vue. If you don't know what WebSockets are, you don't really need to, just think about them as a channel of continuous two-way communication between a server and browser. How

a client. We will not build a server; instead, we'll use an already existing server that just echoes whatever you send to it via WebSockets. So, if we were to send the Hello message, the server would respond with Hello. You will build a chat app that will talk to

use the n special character that means a new line. For our chat to work, we first have to declare our WebSocket in the JavaScript: const ws = new WebSocket('ws://echo.websocket.org') After that, we declare our Vue instance that will contain a chat string (to contain the chat so far) and

developer tools ( | More tools | Developer tools or Opt + Cmd + I): Go to the Network tab and reload the page; you should see the echo.websocket.orl WebSocket, as seen in the screenshot. Write something and messages will appear in the frame tab, like so: The green messages are sent from you while

the sense that they don't need the page to reload for them to be updated. The most common way to implement this is through WebSockets. In this recipe, we will leverage Feathers and Socket.io to build a cat database. Getting ready There is no prerequisite for this recipe, but

app = feathers() .configure(feathers.socketio(socket)) const catService = app.service('cats') This is for configuring the client for the browser that will connect to the WebSockets. The catService method is a handle to the cat database. Next, we write the Vue instance: new Vue({ el: '#app', data: { cats: [], newName: '', newUrl: '' }, methods

. Feathers lets you create them in a snap and with a fraction of the code, thanks to the underlying Socket.io, which in turn uses WebSockets. WebSockets are really not that complex and what Feathers does in this case is just listen for messages in the channel and associate them with actions

like adding something to the database. The power of Feathers is visible when you can just swap database and WebSocket provider, or switch to REST, without even touching your Vue code. Creating a reactive app with Horizon Horizon is a platform to build reactive, real

Mastering Blockchain: Unlocking the Power of Cryptocurrencies and Smart Contracts

by Lorne Lantz and Daniel Cawrey  · 8 Dec 2020  · 434pp  · 77,974 words

2 Float Configuration 3 Regulatory Challenges Banking Risk Exchange Risk Basic Mistakes Exchange APIs and Trading Bots Open Source Trading Tech Rate Limiting REST Versus WebSocket Testing in a Sandbox Market Aggregators Summary 7. Decentralizing Finance and the Web Redistribution of Trust Identity and the Dangers of Hacking Wallets Private Keys

following: Runs on powerful servers with fast network connectivity API calls are designed to accommodate many different trading strategies Support for both REST (pull) and WebSockets (push) High rate limits Follows industry-standard security schemes, such as OAuth 2, popularized by Facebook, or HMAC, which uses hash computation Documentation is presented

per second for other endpoints. The external server will get a 429 error when it makes a request that has exceeded the limit. REST Versus WebSocket Speed is an important factor in building a high-quality trading bot, so that the bot can read the market and execute trades before others

can make a valid request. A faster way for a trading bot to view the current state of the market is by subscribing to a WebSocket. With this setup, as soon as a change occurs in the market, the exchange’s server pushes a notification to all subscribers of the

WebSocket. Then all trading bots subscribing to the WebSocket will receive the same information at the same time, and they do not need to make additional API requests that will fill

API calls, Open Source Trading Tech market aggregators, Market Aggregators open source trading tech, Open Source Trading Tech rate limiting, Rate Limiting REST versus WebSocket, REST Versus WebSocket testing in a sandbox, Testing in a Sandbox application binary interface (ABI), Interacting with a smart contract application-based blockchain transactions, Ether and Gas

APIs and Trading Bots-Market Aggregatorsmarket aggregators, Market Aggregators open source trading tech, Open Source Trading Tech rate limiting, Rate Limiting REST versus WebSocket APIs, REST Versus WebSocket testing trading bot in sandbox, Testing in a Sandbox exchanges, The Role of Exchanges-The Role of Exchanges order books, Order Books regulatory challenges

attacks, Replay attacksprotecting against, on Ethereum and Ethereum Classic, The Ethereum Classic Fork replication systems, Databases and Ledgers REST APIsEthereum network, Interacting with Code WebSocket versus, REST Versus WebSocket ring confidential transactions, Blockchains to Watch, How Monero Works ring signatures, Monero, Ring Signatures, Blockchains to Watchhiding public address of sender on Monero

, Web 3.0 web browsers, giving away user data, Web 3.0 web wallets, Wallet Type Variations Web3.js library, Interacting with Code WebSocket versus REST APIs, REST Versus WebSocket whales, Whales whitelisting addresses, Counterparty Risk whitepapers“Bitcoin: A Peer-to-Peer Electronic Cash System” , The Whitepaper for ICOs, Whitepaper WikiLeaks, Bitcoin

JavaScript Cookbook

by Shelley Powers  · 23 Jul 2010  · 1,038pp  · 137,468 words

both are currently in Working Draft state: CORS at http://www.w3.org/TR/access-control/ and Web Sockets at http://dev.w3.org/html5/websockets/. CORS is a way of doing cross-domain Ajax calls, and is currently im- plemented in Firefox 3.5 and up, and Safari 4.x

to work in the W3C on a 428 | Chapter 18: Communication Figure 18-1. Demonstration of updates from polled Ajax calls new JavaScript API called WebSockets. Currently only implemented in Chrome, Web- Sockets enables bidirectional communication between server and client by using the send method on the

WebSocket object for communicating to the server, and then at- taching a function to WebSocket’s onmessage event handler to get messages back from the server, as demonstrated in the following code from the

Chromium Blog: if ("WebSocket" in window) { var ws = new WebSocket("ws://example.com/service"); ws.onopen = function() { // Web Socket is connected. You can send data by send() method. ws.send("message to send"); .... }; ws

.onmessage = function (evt) { var received_msg = evt.data; ... }; ws.onclose = function() { // websocket is closed. }; } else { // the browser doesn't support WebSocket. } Another approach is a concept known as long polling. In long polling, we initiate an Ajax request as we do now

same functionality with an ARIA live region to ensure the application is accessible for those using screen readers. The W3C WebSockets API specification is located at http://dev.w3.org/html5/websockets/, and the 18.9 Using a Timer to Automatically Update the Page with Fresh Data | 429 Chrome introduction of support

for WebSockets is at http://blog.chromium.org/2009/ 12/web-sockets-now-available-in-google.html. 18.10 Communicating Across Windows with PostMessage Problem Your application

, collapsible sidebars, 292–295 162 hiding elements until needed, 276–277 onload events, 117–118 hover-based pop-up windows, 289–292 onmessage event handler (WebSocket), 429 measuring area of window, 270–271 onmouseout event, for hover-based pop-up overlays for pages, 281–283 windows, 289 adding keyboard accessibility to

Vue.js

by Callum Macrae  · 23 Feb 2018  · 296pp  · 41,381 words

The Art of Monitoring

by James Turnbull  · 1 Dec 2014  · 514pp  · 111,012 words

HTML5 Cookbook

by Christopher Schmitt and Kyle Simpson  · 13 Sep 2011  · 435pp  · 62,013 words

Exploring ES6 - Upgrade to the next version of JavaScript

by Axel Rauschmayer  · 3 Oct 2015

Monadic Design Patterns for the Web

by L.G. Meredith  · 214pp  · 14,382 words

HTML5 Canvas

by Steve Fulton and Jeff Fulton  · 2 May 2013  · 1,881pp  · 178,824 words

The Architecture of Open Source Applications

by Amy Brown and Greg Wilson  · 24 May 2011  · 834pp  · 180,700 words

The Tangled Web: A Guide to Securing Modern Web Applications

by Michal Zalewski  · 26 Nov 2011  · 570pp  · 115,722 words

Redis Cookbook

by Tiago Macedo and Fred Oliveira  · 26 Jul 2011  · 82pp  · 17,229 words

Test-Driven Development With Python

by Harry J. W. Percival  · 10 Jun 2014  · 779pp  · 116,439 words

Eloquent JavaScript: A Modern Introduction to Programming

by Marijn Haverbeke  · 15 Nov 2018  · 560pp  · 135,629 words

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

by Martin Kleppmann  · 16 Mar 2017  · 1,237pp  · 227,370 words

AngularJS

by Brad Green and Shyam Seshadri  · 15 Mar 2013  · 196pp  · 58,122 words

Programming Rust: Fast, Safe Systems Development

by Jim Blandy and Jason Orendorff  · 21 Nov 2017  · 1,331pp  · 183,137 words

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

by Martin Kleppmann  · 17 Apr 2017

Elixir in Action

by Saša Jurić  · 30 Jan 2019

Hands-On RESTful API Design Patterns and Best Practices

by Harihara Subramanian  · 31 Jan 2019  · 422pp  · 86,414 words

Pragmatic Guide to JavaScript

by Christophe Porteneuve  · 15 Nov 2010  · 141pp  · 9,896 words

ZeroMQ

by Pieter Hintjens  · 12 Mar 2013  · 1,025pp  · 150,187 words

The Manager’s Path

by Camille Fournier  · 7 Mar 2017

Building Microservices

by Sam Newman  · 25 Dec 2014  · 540pp  · 103,101 words

Full Stack Web Development With Backbone.js

by Patrick Mulder  · 18 Jun 2014  · 190pp  · 52,865 words

Learn Algorithmic Trading

by Sebastien Donadio  · 7 Nov 2019

Chaos Engineering: System Resiliency in Practice

by Casey Rosenthal and Nora Jones  · 27 Apr 2020  · 419pp  · 102,488 words

Mastering Ember.js

by Mitchel Kelonye  · 19 Oct 2014  · 266pp  · 38,397 words

Mastering Ethereum: Building Smart Contracts and DApps

by Andreas M. Antonopoulos and Gavin Wood Ph. D.  · 23 Dec 2018  · 960pp  · 125,049 words

Seeking SRE: Conversations About Running Production Systems at Scale

by David N. Blank-Edelman  · 16 Sep 2018

The TypeScript Workshop: A Practical Guide to Confident, Effective TypeScript Programming

by Ben Grynhaus, Jordan Hudgens, Rayon Hunte, Matthew Thomas Morgan and Wekoslav Stefanovski  · 28 Jul 2021  · 739pp  · 174,990 words