The unbearable lightness of data visualization in Kotlin full stack

Everybody is talking about full stack development. Everything is mostly clear, there is a client (browser), there is a server. The client is the source of the control flow, the server is the source of the data. You can do them in different languages. I like Kotlin the best, of course. But such a scheme is not always suitable.

Sometimes the "server" is the manager, and the "client" only does the rendering. This is a typical situation in process and data visualization systems (e.g., data acquisition systems). Also, it frequently happens that the UI and visualization are done on the web, even when the application is not essentially a web service. Simply because it is more convenient to draw in the browser. In this talk, we will analyze such a situation when the "server" is the client, and the browser is the "server for rendering." The way to organize the reverse flow of control and data model propagation in Kotlin and what unusual problems are connected to such an architecture are described.

Talk material.