Commit 484c4b87 authored by Claude Brisson's avatar Claude Brisson

Integrate Jérôme's remarks

parent 89773332
# Kroom
Kroom intends to be a Kotlin-based framework for virtual rooms, handling presence, user status, authentication and events broadcasting.
Kroom intends to be a Kotlin-based framework for virtual rooms, handling presence, user status, authentication and event 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.
The early days of the HTTP protocol were dedicated to standard HTML websites, with communication always initiated by the client. HTML progressively became 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 spread of HTTP 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.
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 burden of all its attendant 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.
This shortcoming has now been addressed in several ways which will be discussed below. Choosing to not rely on HTTP nowadays means giving up the benefits of many mature inherited protocols (HTTPS, OAuth, ...), and burdening oneself with the systematic need of a heavy client.
### HTML and Mobiles
......@@ -19,23 +19,24 @@ With the popularization of client-side scripting and the maturation of CSS in re
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.
- 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); and
- none of them could afford to forgo HTML interfaces in native applications, as they still rely on 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.
Anyhow, the gap 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.
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 when there are waiting events (which are then send 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:
The most well-known HTTP push technology is the WebSockets protocol (which first appeared in 2008, and became really usable around 2011). But it has several major drawbacks:
- 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
- it is quite complex to set up and to use;
- it is simply not very pertinent: what's the point in introducing a two way binary protocol on top of such a rich and elaborated protocol as HTTP?! Think of it as a kind of *emulation*, which does not bode well in terms of induced complexity; and
- 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.
But there is an older and much simpler protocol which has regained a lot of interest recently: Server-Sent Events (SSE). While it caused some problems with HTTP/1.1, all of those are solved with HTTP/2.
Please refer to online articles such as [this one](https://www.smashingmagazine.com/2018/02/sse-websockets-data-flow-http2/) or [this one](https://medium.com/axiomzenteam/websockets-http-2-and-sse-5c24ae4d9d96) for a deeper analysis of WebSockets vs. SSE.
......@@ -44,11 +45,11 @@ The SSE protocol has the merit of simplicity. It is a text-based protocol, as si
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.
where *data* is a free line of text which we will 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:
Once we have an upstream channel (standard HTTP requests initiated by the client) and a downstream channel (by means of the SSE protocol), our event-based application is designed as follow:
```mermaid
sequenceDiagram
......@@ -67,13 +68,13 @@ Server ->> Client: room-specific SSE push towards targeted users
### Kotlin
The language of choice for asynchronous handling, which has gained a tremendous momentum recently, is [Kotlin](https://kotlinlang.org/). 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 language of choice for asynchronous handling, which has gained a tremendous momentum recently, is [Kotlin](https://kotlinlang.org/). 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 contexts).
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).
The promises of the Kotlin environment go to the extremes of sharing the same business logic codebase for all of the following platforms: 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.
One disclaimer, though: when it comes to Android and iOS, the factorization of the view layer code is still a work in progress. But it's let of a problem if one targets HTML/CSS views, it's less of a problem.
### Ktor
The Kotlin-based [Ktor](https://ktor.io/) framework, with can rely on the lightweight but flawless [Netty](netty.io) web engine, constitute a very strong basis for our envisioned events based webapp.
The Kotlin-based [Ktor](https://ktor.io/) framework, which can rely on the lightweight but flawless [Netty](netty.io) web engine, constitute a very strong basis for our envisioned event-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