Skip to content

Home

Jump to bottom
Micael Pedrosa edited this page Sep 21, 2016 · 6 revisions

Reactive Through Services (RTS)

The RTS platform is born by a necessity of building modern reactive web user interfaces. A User Interface is considered to be "reactive" if any status change in a UI components are reflected immediately, by means of a user input or other external information. The user is always aware of the status of his data by this constant feedback. In the web environment there are many client side libraries that help in this task, on of the most known is ReactiveX. But the client UI is not the whole of the web app. When building information systems it's common to have server side services. The standard (on this time writing) is REST build on top of HTTP protocol. The problems starts here when we are trying to build reactive UI on top of non reactive REST services. A common use case for example, is requesting a background task and receive constant feedback on the ongoing process. REST services are mainly based on Pull network style. Although there are some Push style libraries available on top of HTTP, none is quite well integrated with modern reactive libraries like ReactiveX, I mean the Observable pattern.

##Squaring the Circle There is (from an electronic jargon) impedance mismatch in the reactive UI and the required server side services. Also HTTP is not the best protocol for Push network style, there is a new kid on the block called WebSockets. WebSockets solves a few issues with REST, or HTTP in general:

  • Bi-directional: HTTP is a uni-directional protocol where a request is always initiated by client, server processes and returns a response, and then the client consumes it. WebSocket is a bi-directional protocol where there are no pre-defined message patterns such as request/response. Either client or server can send a message to the other party.
  • Full-duplex: HTTP allows the request message to go from client to server and then server sends a response message to the client. At a given time, either client is talking to server or server is talking to client. WebSocket allows client and server to talk independent of each other.
  • Single TCP Connection: Typically a new TCP connection is initiated for a HTTP request and terminated after the response is received. A new TCP connection need to be established for another HTTP request/response. For WebSocket, the HTTP connection is upgraded using standard HTTP Upgrade mechanism and client and server communicate over that same TCP connection for the lifecycle of WebSocket connection.
  • Lean protocol: HTTP is a chatty protocol. Here is the set of HTTP headers sent in request message by Advanced REST Client Chrome extension.
POST /websocket-vs-rest-payload/webresources/rest HTTP/1.1\r\n
Host: localhost:8080\r\n
Connection: keep-alive\r\n
Content-Length: 11\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36\r\n
Origin: chrome-extension://hgmloofddffdnphfgcellkdfbfbjeloo\r\n
Content-Type: text/plain \r\n
Accept: */*\r\n
Accept-Encoding: gzip,deflate,sdch\r\n
Accept-Language: en-US,en;q=0.8\r\n
\r\n

However there is a lack of standardization for Push services, the brother of REST services!

Clone this wiki locally