Commit 89773332 authored by Claude Brisson's avatar Claude Brisson

Kroom gist

parent 76c7b4dd
# Kroom
Kroom intends to be a Kotlin-based framework for virtual rooms, handling presence, user status, authentication and events broadcasting.
## Choosing the right technologies for an event-based application
### Client-Server considerations
The early days of the HTTP protocol were dedicated to standard HTML websites, with exchanges always initiated by the client. HTML became progressively a de facto standard for user interfaces, even outside the browser (Android and iOS being two notable exceptions, see below), especially when enriched with client-side scripting and ajax calls, while HTTP became more and more widespread, incorporating many security and authentication schemes, even for server to server communications with the banalization of APIs.
But the lack of push abilities (aka letting the client know that some event happened on the server side without having the client initiate a request) let many developers stick to low-level socket-based communications, implying heavy clients, with the train of all their burden of packaging and support problems.
This shortcoming has now been addressed in several ways that we should look at below. Choosing to not rely on HTTP nowadays is waiving the use of many mature inherited protocols (HTTPS, OAuth, ...), let alone the systematic need of an heavy client.
### HTML and Mobiles
With the popularization of client-side scripting and the maturation of CSS in regard to responsive designs, HTML has now become an almost limitless UI platform and our browsers can host the most complex user interfaces.
Yet, Android and iOS are still trying to promote (with some success) their own heavy client view technologies. But one should recall that Android and iOS are supported by private corporations which have always tried to influence the technology market in their favor. But despite their efforts:
- they cannot offer the same robustness and evolutivity as HTML based UIs ; each of their new major versions introduces several evolutions and limitations which make the maintenance of native apps difficult.
- they propose a fragmented environment where one publisher has to maintain three code bases, one for the web, one for Android, one for iOS (and did a lot of harm to the publishers not being able to address such a fragmentation of the market)
- none of them could afford to close the door to the use of HTML interfaces in native aplications, by means of HTML view components which can even receive native events (like gestures) in Javascript.
Anyhow, the distance between single-page webapps and native applications is narrowing everyday.
### Push vs. Pull
Before the emergence of push technologies, one had to use polling to broadcast to clients events emitted by the server. Among the different variations of polling, the only reliable one is the *long polling*, where the client sends regular requests to the server, which only answers whenever there are waiting events (and which sends the events in batch). Whatever subsequent push technology is used, one should *always* have a fall-back mechanism involving long polling as a fail safe.
The most well-known HTTP push technology is the WebSockets protocol (which first appeard in 2008, and became really usable around 2011). But it has several major inconvenients:
- it is quite complex to set up and to use
- it is simply not very pertinent: what's the point in introducing a two ways binary protocol on top of such a rich an elaborated protocol as HTTP?! Think of it as a kind of *emulation*, which does not bode well in terms of induced complexity
- it is not well-suited for HTTP/2
But there is an older and much simpler protocol which has gained back a lot of interest recently: Server-Sent Events (SSE). While it posed some problems with HTTP/1.1, all of those are solved with HTTP/2.
Please refer to online articles such as [this one]( or [this one]( for a deeper analysis of WebSockets vs. SSE.
The SSE protocol has the merit of simplicity. It is a text-based protocol, as simple as:
event: chat
data: { "from":"Bob", "to":"Alice", "message":"Hello there!" }
where *data* is a free line of text which we'll choose, of course, to be a JSON object describing the event data.
### Actions and Events
Once we have an upstream channel (standard HTTP requests initiated by the client) and a downstream channel (by meands of the SSE protocol), our event-based application is architectured as follow:
Note right of Client: User action<br/>(mouse / keyboard)
Client ->> Server: HTTP API call (GET/PUT/POST/DELETE)
Note right of Client: Server synchronous<br/>response, mainly<br/>success/error
Server ->> Client: user-specific HTTP answer
loop asynchronous
Server ->> Server: logic application processing
Note right of Client: Events broadcasting
Server ->> Client: room-specific SSE push towards targeted users
## Language and web framework
### Kotlin
The language of choice for asynchronous handling, which has gained a tremendous momentum recently, is [Kotlin]( Think of it as a strongly typed language, but far less verbose than Java (with which it is interoperable) with powerful syntax constructs and concurrency features (coroutines and execution contextes).
The promises of the Kotlin environment go to the extremes of sharing the same business logic codebase to address all of the following platform: the JVM, Android, iOS, Javascript (and all other native environments).
One disclaimer, though: when it comes to Android and iOS, the factorization of the view layer code is still emerging. But if one targets HTML/CSS views, it's less of a problem.
### Ktor
The Kotlin-based [Ktor]( framework, with can rely on the lightweight but flawless [Netty]( web engine, constitute a very strong basis for our envisioned events based webapp.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment