|
1 | | -Using F# on both client and server is at the core of the SAFE stack, as it simplifies the way we think about building web applications by using the same language, idioms and in many cases sharing our code and domain models. |
2 | | - |
3 | | -However, building a client and a server app requires a fundamentally different way of thinking. On the server side we build [stateless APIs in Saturn](component-saturn.md) that map HTTP requests to internal functionality, whereas on the frontend we use the Elmish model, implementing the [model-view-update pattern](component-elmish.md): a stateful pattern that lets us think about the application state as it evolves while the application is running. |
4 | | - |
5 | | -Even though we use the same language across platforms, applying these two different programming models forces us to switch our way of thinking back and forth when writing code for the client and for the server. This is where the [Elmish.Bridge](https://github.com/Nhowka/Elmish.Bridge) library comes into play: it brings the Elmish programming model *to the server* and unifies the way we write the application as a whole. |
6 | | - |
7 | | -## How does Elmish work on the server? |
8 | | -Think of Elmish on the server as the model-view-update pattern but *without the view part*. Instead, you only need to implement `init` and `update` functions to manage the *server* state as it evolves while the server is running. |
9 | | - |
10 | | -* Server state can contain data that is relevant to a single or all clients |
11 | | -* The dispatch loop running on the server is connected to the dispatch loop on the client via a *persistent stateful websocket connection* |
12 | | -* The `update` functions on client and server can exchange data via message passing. |
13 | | - |
14 | | -## A simple example |
15 | | -Let's see a simple example of how this might work in practice: |
16 | | - |
17 | | -```fsharp |
18 | | -// Client-side |
19 | | -let update msg state = |
20 | | - match msg with |
21 | | - | LoadUsers -> |
22 | | - // send the message to the server |
23 | | - state, Cmd.bridgeSend ServerMsg.LoadUsers |
24 | | - | UsersLoaded users -> |
25 | | - // receive message from the server |
26 | | - let nextState = { state with Users = users } |
27 | | - nextState, Cmd.none |
28 | | -
|
29 | | -// Server-side |
30 | | -let update clientDispatch msg state = |
31 | | - match msg with |
32 | | - | ServerMsg.LoadUsers -> |
33 | | - let loadUsersCmd = |
34 | | - Cmd.ofAsync |
35 | | - getUsersFromDb // unit -> Async<User list> |
36 | | - () // input arg = unit |
37 | | - UsersLoadedFromDb // User list -> ServerMsg |
38 | | - DoNothing // ServerMsg |
39 | | - state, loadUsersCmd |
40 | | -
|
41 | | - | ServerMsg.UsersLoadedFromDbSuccess users -> |
42 | | - // answer the current connected client with data |
43 | | - clientDispatch (ClientMsg.UsersLoaded users) |
44 | | - state, Cmd.none |
45 | | -
|
46 | | - | ServerMsg.DoNothing -> |
47 | | - state, Cmd.none |
48 | | -``` |
49 | | - |
50 | | -The above example mimics what would have been a `GET` request to the server to get user data from database. However, now the client sends a fire-and-forget message to the server to load users, and at some point the server messages the current client back with the results. Notice that the server could have decided to do other things than just messaging the client back: for example, it could have broadcasted the same message to other clients updating their local state of the users. |
51 | | - |
52 | | -## When to use Elmish.Bridge |
53 | | -There are many scenarios where it makes sense to use Elmish.Bridge: |
54 | | - |
55 | | -* Chat-like applications with many connected users through many channels |
56 | | -* Syncing price data in real-time while viewing ticket prices |
57 | | -* Multiplayer games that need real-time update of game states |
58 | | -* Other applications of web sockets through an Elmish model |
59 | | - |
60 | | -## Things to consider |
61 | | -The biggest distinction between using this and "raw" Saturn is that your web server becomes a stateful service. This introduces several differences for application design. |
62 | | - |
63 | | -1. The server state has a lifespan equal to the that of the process under which the server instance is running. This means if the server application restarts then the server state will be reset. |
64 | | - |
65 | | -2. The server state is *local to the server instance*. This means that if you run multiple web servers, they won't be sharing the same server state by default. |
66 | | - |
67 | | -As of now there is no built-in persistence for the state, but you can implement this yourself using any number of persistance layers such as Redis Cache, Azure Tables or Blobs etc. |
68 | | - |
69 | | -In addition Elmish.Bridge does not use standard HTTP verbs for communication, but rather websockets. Therefore, it is not a suitable technology for an open web server that can serve requests from other sources than Elmish.Bridge clients. |
70 | | - |
71 | | -## Learn more about Elmish.Bridge |
72 | | -Head over to [Elmish.Bridge](https://github.com/Nhowka/Elmish.Bridge) to learn more. |
| 1 | +Using F# on both client and server is at the core of the SAFE stack, as it simplifies the way we think about building web applications by using the same language, idioms and in many cases sharing our code and domain models. |
| 2 | + |
| 3 | +However, building a client and a server app requires a fundamentally different way of thinking. On the server side we build [stateless APIs in Saturn](../components/component-saturn.md) that map HTTP requests to internal functionality, whereas on the frontend we use the Elmish model, implementing the [model-view-update pattern](../components/component-elmish.md): a stateful pattern that lets us think about the application state as it evolves while the application is running. |
| 4 | + |
| 5 | +Even though we use the same language across platforms, applying these two different programming models forces us to switch our way of thinking back and forth when writing code for the client and for the server. This is where the [Elmish.Bridge](https://github.com/Nhowka/Elmish.Bridge) library comes into play: it brings the Elmish programming model *to the server* and unifies the way we write the application as a whole. |
| 6 | + |
| 7 | +## How does Elmish work on the server? |
| 8 | +Think of Elmish on the server as the model-view-update pattern but *without the view part*. Instead, you only need to implement `init` and `update` functions to manage the *server* state as it evolves while the server is running. |
| 9 | + |
| 10 | +* Server state can contain data that is relevant to a single or all clients |
| 11 | +* The dispatch loop running on the server is connected to the dispatch loop on the client via a *persistent stateful websocket connection* |
| 12 | +* The `update` functions on client and server can exchange data via message passing. |
| 13 | + |
| 14 | +## A simple example |
| 15 | +Let's see a simple example of how this might work in practice: |
| 16 | + |
| 17 | +```fsharp |
| 18 | +// Client-side |
| 19 | +let update msg state = |
| 20 | + match msg with |
| 21 | + | LoadUsers -> |
| 22 | + // send the message to the server |
| 23 | + state, Cmd.bridgeSend ServerMsg.LoadUsers |
| 24 | + | UsersLoaded users -> |
| 25 | + // receive message from the server |
| 26 | + let nextState = { state with Users = users } |
| 27 | + nextState, Cmd.none |
| 28 | +
|
| 29 | +// Server-side |
| 30 | +let update clientDispatch msg state = |
| 31 | + match msg with |
| 32 | + | ServerMsg.LoadUsers -> |
| 33 | + let loadUsersCmd = |
| 34 | + Cmd.ofAsync |
| 35 | + getUsersFromDb // unit -> Async<User list> |
| 36 | + () // input arg = unit |
| 37 | + UsersLoadedFromDb // User list -> ServerMsg |
| 38 | + DoNothing // ServerMsg |
| 39 | + state, loadUsersCmd |
| 40 | +
|
| 41 | + | ServerMsg.UsersLoadedFromDbSuccess users -> |
| 42 | + // answer the current connected client with data |
| 43 | + clientDispatch (ClientMsg.UsersLoaded users) |
| 44 | + state, Cmd.none |
| 45 | +
|
| 46 | + | ServerMsg.DoNothing -> |
| 47 | + state, Cmd.none |
| 48 | +``` |
| 49 | + |
| 50 | +The above example mimics what would have been a `GET` request to the server to get user data from database. However, now the client sends a fire-and-forget message to the server to load users, and at some point the server messages the current client back with the results. Notice that the server could have decided to do other things than just messaging the client back: for example, it could have broadcasted the same message to other clients updating their local state of the users. |
| 51 | + |
| 52 | +## When to use Elmish.Bridge |
| 53 | +There are many scenarios where it makes sense to use Elmish.Bridge: |
| 54 | + |
| 55 | +* Chat-like applications with many connected users through many channels |
| 56 | +* Syncing price data in real-time while viewing ticket prices |
| 57 | +* Multiplayer games that need real-time update of game states |
| 58 | +* Other applications of web sockets through an Elmish model |
| 59 | + |
| 60 | +## Things to consider |
| 61 | +The biggest distinction between using this and "raw" Saturn is that your web server becomes a stateful service. This introduces several differences for application design. |
| 62 | + |
| 63 | +1. The server state has a lifespan equal to the that of the process under which the server instance is running. This means if the server application restarts then the server state will be reset. |
| 64 | + |
| 65 | +2. The server state is *local to the server instance*. This means that if you run multiple web servers, they won't be sharing the same server state by default. |
| 66 | + |
| 67 | +As of now there is no built-in persistence for the state, but you can implement this yourself using any number of persistance layers such as Redis Cache, Azure Tables or Blobs etc. |
| 68 | + |
| 69 | +In addition Elmish.Bridge does not use standard HTTP verbs for communication, but rather websockets. Therefore, it is not a suitable technology for an open web server that can serve requests from other sources than Elmish.Bridge clients. |
| 70 | + |
| 71 | +## Learn more about Elmish.Bridge |
| 72 | +Head over to [Elmish.Bridge](https://github.com/Nhowka/Elmish.Bridge) to learn more. |
0 commit comments