Interactive Frontend Development

name: bidirectional
class: cols, middle, main

.fifty.main-left[
# Interactive Front-end Development

by Artem Halas and Stanislav Deviatykh
]
.fifty.main-right[.main-circle[].secondary-circle[]]

???

Presenter display slide notes

Pre-lecture checklist

* Switching between mirroring and non-mirroring works
* Unrelated tabs and windows closed or minimized
* Do not disturb mode **ON**
* Slides cloned, one has presenters mode on
* Dependencies installed and scripts are working for lecture example code
* Terminal(s) open with code and window to run scripts

---

# Evaluating libraries/frameworks

* What are the basic abstractions?
* How well do they **compose**?

---

# React & Reducers

* Stateless React components
  * compose trivially through containment
  * **no state**, no _gotchas_, no complexity
* Reducers
  * **Pure functions** compose whichever way you want

---

# React & Reducers

* New abstractions or small helper functions are easy to use because the core
  abstractions are pure functions

```js
(props) => pseudoHtml
```

```js
(action, previousState) => newState
```
 
---

# Why all this functional programming nonsense?

Can’t I just hack things together?

---

# Why all this functional programming nonsense?

* It **is not difficult** to hack together a prototype
* It **is difficult** to build maintainable software

---

# Communication with remote servers

* HTTP APIs can be consumed in browsers via `fetch`
* `fetch` is **unidirectional**, a server cannot make a request to the browser
  * e.g. _You have one new message_
* Some web applications require **bidirectional** communication to push updates to the browser

---

# Long polling

* HTTP requests can be hacked to achieve bidirectional communication
* [https://en.wikipedia.org/wiki/Push_technology#Long_polling](https://en.wikipedia.org/wiki/Push_technology#Long_polling)

---

# Long polling

* Client sends request to Server
* Server does not respond immediately and keeps connection open 
* When the server has information to _push_ to the Client, the Server sends a response to the open connection
* Client receives response from Server containing the pushed information
* Client immediately sends a new request to Server
* Rinse and repeat, connection kept open until user on page

---

# Long polling

<figure>
  <img src="./assets/lecture-6/long-polling.png" alt="Long polling" style="width:100%">
  <figcaption>https://javascript.info/long-polling</figcaption>
</figure>

---

# WebSockets

* All modern Web Browsers support
  [WebSockets](https://developer.mozilla.org/en-US/docs/Web/API/WebSocket)
  which is a saner alternative
* Note that simply polling (requesting data at an interval) is a valid
  simplification for many applications

---

# WebSockets
   
* `connection.onopen = callback`

connection between Client and Server is established

* `connection.onclose = callback`

connection is closed by Server or Client or when connection is disrupted

* `connection.onmessage = callback`

Client received messages pushed from Server
             
---

# WebSockets

* `connection.send(utf8String)`

send string-type message to Server (binary messages also supported)

* `connection.close()`

close connection from Client
             
---

# Websockets

* Websockets (and web requests) are an epitome of mutable state.

* You never know **what**, **if** and **when** is coming from them.

* Put them under tight supervision, **do not** leak them all over our beautiful application code

---

# Code example

[WebSocket example app](https://github.com/urmastalimaa/interactive-frontend-development/tree/master/lecture_6)

---

# Testing WebSockets

* WebSocket connections are initiated using the WebSocket global
* WebSocket connections are inherently stateful
* All this make testing WebSockets directly rather inconvenient

---

# Testing WebSockets

Some libraries provide mock implementations of WebSocket global
([https://github.com/thoov/mock-socket](https://github.com/thoov/mock-socket))

But generally, it is simplest to

* avoid depending on intimate details of the WebSocket interface
* provide a mock using simple "stub" functions

[WebSocket example app test](https://github.com/urmastalimaa/interactive-frontend-development/tree/master/lecture_6/test/AppTest.js)

---

# Distributed systems

This is not a course on distributed systems, but...

.full-image[![servers](assets/lecture-6/servers.jpeg)]

---

# Distributed systems

From the moment a remote Server is introduced, a distributed system is created

In a distributed system it is important to understand

* who **owns** (modifies and can be queried for) what information
* how updates are broadcasted / subscribed to
* what are the message delivery guarantees of communication channels

---

# Distributed systems

It is **very easy** to create an inconsistent system

Difficulting in retaining consistency increases when more moving parts are
added to a system (e.g multiple processes for load balancing/resiliency)

---

# Distributed systems

Before using any technology that can be _connected_ to

* HTTP requests,
* WebSockets,
* (NoSQL, relational) databases,
* etc

understand message **delivery and consistency guarantees**

---

# WebSocket delivery guarantees

* WebSockets use a single TCP connection,
* messages are guaranteed to arrive **in-order** and **exactly-once**
* as long as the connection is alive
* [https://tools.ietf.org/html/rfc6455](https://tools.ietf.org/html/rfc6455)

**As long as the connection is alive**

???

In practice connections are arbitrarily closed all the time

---