diff --git a/common-content/en/module/decomposition/adding-like-dislike/index.md b/common-content/en/module/decomposition/adding-like-dislike/index.md new file mode 100644 index 000000000..d7f750691 --- /dev/null +++ b/common-content/en/module/decomposition/adding-like-dislike/index.md @@ -0,0 +1,64 @@ ++++ +title = "Adding like/dislike" +headless = true +time = 120 +facilitation = false +emoji= "👍👎" +objectives = [ + "Identify what data needs to be stored and exchanged between a client and server.", + "Devise a scheme for differentiating messages with different meanings (e.g. a new message vs a new like).", + "Contrast giving updated values as absolute values or relative changes.", + "Implement an end-to-end feature involving data updates and reconciliation across a client and server.", +] ++++ + +The last requirement we have for our chat application is the ability to like/dislike a message (and see what messages have been liked/disliked). + +{{}} +Think about what information a client would need to provide to a server in order to like/dislike a message. + +Think about what information a server would need to provide to a client in order to display how many likes/dislikes a message has. + +Think about what information a server would need to provide to a client in order to _update_ how many likes/dislikes a message has. + +Write these things down. +{{}} + +### Identifiers + +One of the key new requirements to add liking/disliking a message is knowing _which_ message is being liked/disliked. + +When a client wants to like a message, it needs some way of saying _this_ is the message I want to like. + +This suggests we need a unique identifier for each message: +* When the server tells a client about a message, it needs to tell it what the identifier is for that message. +* When a client tells the server it wants to like a message, it needs to tell it the identifier for the message it wants to like. +* When the server tells a client a message has been liked, it needs to tell the client which message was liked, and the client needs to know enough about that message to be able to update the UI. + +### Message formats + +Now that your server will be sending multiple kinds of updates ("Here's a new message", or "Here's an update to the number of likes of an existing message"), you'll need to make sure the client knows the difference between these messages. The client will need to know how to act when it receives each kind of message. + +### Changes or absolutes? + +When new likes happen, a choice we need to make is whether the server should tell a client "this message was liked again" or should tell the client "this message now has 10 likes". Both of these can work. + +{{}} +Write down some advantages and disadvantages of a server -> client update being "+1 compared to before" or "now =10". + +Choose which approach you want to take. +{{}} + +{{}} +Implement liking and disliking messages. + +If a message has a non-zero number of likes or dislikes, the frontend needs to show this. + +The frontend needs to expose some way for a user to like or dislike any message. + +When a user likes or dislikes a message, the frontend needs to tell the backend about this, and the backend needs to notify all clients of this. + +When a frontend is notified by a backend about a new like or dislike, it needs to update the UI to show this. + +You may do this in your polling implementation, WebSockets implementation, or both. +{{}} diff --git a/common-content/en/module/decomposition/chat-application-requirements/index.md b/common-content/en/module/decomposition/chat-application-requirements/index.md new file mode 100644 index 000000000..514346625 --- /dev/null +++ b/common-content/en/module/decomposition/chat-application-requirements/index.md @@ -0,0 +1,40 @@ ++++ +title = "Chat application requirements" +headless = true +time = 30 +facilitation = false +emoji= "📝" +objectives = [ + "Explain the requirements of our chat application.", + "Explain what requirements are out of scope for our chat application.", +] ++++ + +We are going to make a chat application which lets multiple users exchange messages. + +Let's think about the core requirements for our application: +* As a user, I can send add a message to the chat. +* As a user, when I open the chat I see the messages that have been sent by any user. +* As a user, when someone sends a message, it gets added to what I see. +* As a user, I can "like" or "dislike" someone's message. +* When messages are liked or disliked, a count of the likes and dislikes is displayed next to the message. + +We can imagine other requirements too (e.g. replying to specific messages, reacting with emojis, being able to edit or delete messages, registering exclusive use of a username, ...). We will stick just to the requirements we've listed. + +Because users want to see things, we know we'll need a frontend. + +Because multiple users want to be able to share information (messages), we know we'll need a backend for them to communicate via. + +### What we already know and what's new + +Some of these requirements are similar to the quote server we've already implemented: +* Adding messages is like adding quotes. +* Seeing messages is like seeing quotes. + +Others are new: +* Live updates +* Interacting with a message + +First let's make a backend and a frontend to do what we already know. This shouldn't take us very long (we know how to do it, and have done it recently). It will give us a useful framework to experiment with the things that are new to us. + +If we thought it would take us a long time to do what we already know, we may approach this differently. We would probably try to work out the new things first. Because they may change how we want to do everything. But because it should be quick to do what we do know, we'll start there. diff --git a/common-content/en/module/decomposition/deploy-chat-application/index.md b/common-content/en/module/decomposition/deploy-chat-application/index.md index 4a70cb92c..26d8996c7 100644 --- a/common-content/en/module/decomposition/deploy-chat-application/index.md +++ b/common-content/en/module/decomposition/deploy-chat-application/index.md @@ -1,11 +1,14 @@ +++ title = "Deploying the chat application" headless = true -time = 30 +time = 60 facilitation = false -emoji= "📖" -[objectives] - 1="Deploy all components of a frontend/backend/database application so it can be used on the internet" +emoji= "➡️" +objectives = [ + "Deploy a frontend and backend so it can be used on the internet.", +] +++ -### Deploying the chat application +{{}} +Deploy your chat application so that both the frontend and backend are on the Internet, can talk to each other, and can be used by people. +{{}} diff --git a/common-content/en/module/decomposition/designing-streaming-api/index.md b/common-content/en/module/decomposition/designing-streaming-api/index.md new file mode 100644 index 000000000..e2519d671 --- /dev/null +++ b/common-content/en/module/decomposition/designing-streaming-api/index.md @@ -0,0 +1,46 @@ ++++ +title = "Designing a streaming API" +headless = true +time = 30 +facilitation = false +emoji= "🧑‍🔬" +objectives = [ + "Describe the trade-offs of different streaming APIs.", +] ++++ + +So far we have a frontend that asks a backend for all of its chat messages, and shows them. + +We want the frontend to find out about new messages. + +One way we could do this is for our frontend to frequently ask our backend for all of its messages. We could then either re-render the page with all of the messages, or we could work out which messages are new and add them to the UI. + +This approach can work, but it is {{}}When we use the word expensive, we don't always mean in terms of money. Sometimes we mean something is slow, something will use a lot of memory, or will use a lot of some other resource{{}}. In this case, the reason it's expensive is that it involves sending a lot of data over the network. Often the _same_ data _repeatedly_. + +A cheaper approach would be for the client to be able to ask only for the new messages. But this is a more complicated question than it seems. What does "new" mean? New since when? + +We can divide approaches to identifying new messages based on whose job it is to answer the question "since when?". + +### Remembering "since when" on the client + +If the server tells the client, in its response, some identifier for its newest message (e.g. the timestamp, or some ID), the client could ask in its next request "Please give me all messages since this timestamp". + +The client would need to remember the last timestamp/ID it has seen. + +The server will need to be able to answer that question: "What messages have been sent since this time?". + +There are a few ways we can support this on the server: +1. If we're storing messages in an array, in all our responses we could tell the client what the last index we returned to it was. Then the server could just `slice` the array to get the values to return. +2. Or if we don't want to expose array indexes (e.g. because perhaps messages can be deleted), we could put a timestamp in every message object, and `filter` our array based on the timestamp we're searching from. + +### Remembering "since when" on the server + +The server could remember, for each client, what the last message it sent to that client was. + +The client would no longer need to remember the last timestamp/ID it had been sent. It would just ask for new messages. + +The server would need a way of identifying which client is making a request, and would itself need to remember which messages it had already sent that client. + +This simplifies things for the client, but means that the server needs to remember information for each client it has. If there are a lot of clients, this may be a lot of work, and take up a lot of memory. One challenge with this approach is that the server needs to know when it can forget about a client - if it never forgets about clients, it will keep using more and more memory to track this information for every client it's ever had. And we probably can't rely on a client to tell our backend "you can forget about me now". + +We will try out both of these approaches in two different frontends to the same backend. diff --git a/common-content/en/module/decomposition/long-polling-requests/index.md b/common-content/en/module/decomposition/long-polling-requests/index.md deleted file mode 100644 index 699008805..000000000 --- a/common-content/en/module/decomposition/long-polling-requests/index.md +++ /dev/null @@ -1,13 +0,0 @@ -+++ -title = "Long-polling requests" -headless = true -time = 30 -facilitation = false -emoji= "📖" -[objectives] - 1="Identify the limitations of loading a website via a single request and response" - 2="Give examples of functionality that relies on subsequent data transfer from the server to the client" - 3="Identify and explain why clients typically initiate requests" -+++ - -### Long-polling requests diff --git a/common-content/en/module/decomposition/long-polling/index.md b/common-content/en/module/decomposition/long-polling/index.md new file mode 100644 index 000000000..044815da2 --- /dev/null +++ b/common-content/en/module/decomposition/long-polling/index.md @@ -0,0 +1,85 @@ ++++ +title = "Long-polling" +headless = true +time = 90 +facilitation = false +emoji= "⏳" +objectives = [ + "Stream live updates from a server by using long-polling.", + "Compare the trade-offs involved with frequent small requests vs long-polling.", +] ++++ + +We noticed when we were repeatedly polling for updates that we were making lots of requests, and a lot of their responses were empty. + +Another approach we could take is to make an HTTP request, but have the server not respond to it until there is a non-empty response. + +One request gets one response, but the server can take some time to make that response. + +This is _also_ expensive, but in a different way. + +### Different kinds of expensive + +Making lots of requests was expensive because establishing connections takes time, CPU, and network resource. And on the server calculating that there were no new messages to respond with took a bit of time. + +Keeping requests open for a long time is expensive because it means the server needs to keep all of the resources associated with a request open. The whole time the request is waiting, the server needs to keep the TCP connection open, needs to keep the memory associated with the request, needs to remember that it should respond to it (and how to). It also means that we need to be careful about restarting the server (e.g. if we change its code and want to run the new code) - stopping the server will break any connections that are waiting. + +When we were making lots of small quick connections, we could do things like start a new server, shift over all new traffic to it, and turn off the old server. This was easy for us to do because each request was quick, so we knew when we switched to the new server, any requests to the old server would be done quickly, and it wouldn't get any more. + +Now that we're using long connections, if we turn on a new server and switch new requests to it, it may still be a while before the old server's requests are finished. + +In different contexts, it may be worse to have lots of short requests, or fewer longer requests. + +### Changing our code to support long-polling + +On the client side, we probably don't need to change anything about our code. Just the requests it makes may take longer to resolve. + +On the server side, we will need to change things around. Right now, our `GET` handler _always_ responds based on what it currently knows. + +We want to change this. + +If we don't have any messages to respond with, we want to wait until we _do_ have something to respond with. + +We know `res.send` is a callback function - it's a function we can call when we have a response to send. + +Now we don't always want to call `res.send` in our handler. Sometimes we want to say: "When we next get a message, call `res.send` with that message". + +This means we need to share our callback between the `GET` handler for asking about new messages, and the `POST` handler for sending new messages. + +When the `POST` handler saves a new message, we want to check if there are any `GET` handlers waiting for a message, and call those `GET` handlers' `res.send` callbacks with the new message. + +To achieve this, we probably want to make a new piece of state on our server where we can remember which callbacks still need to be called with responses: + +```js +const callbacksForNewMessages = []; +``` + +In our `GET` handler, we want to write some code to remember that someone of our callbacks aren't being instantly called, and will need calling in the future: + +```js +if (messagesToSend.length === 0) { + // Note: We need to use an arrow function here, rather than just pushing `res.send` directly. + // This is because of handling of "this". + // You can read about "this" at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this + callbacksForNewMessages.push((value) => res.send(value)); +} else { + res.send(messagesToSend); +} +``` + +and in our `POST` handler, when we are saving a new message we want to run some code to call any callbacks which are still waiting for a response when we get a new message: + +```js +while (callbacksForNewMessages.length > 0) { + const callback = callbacksForNewMessages.pop(); + callback([newMessage]); +} +``` + +Note how we're wrapping `newMessage` in an array - we need to return the same type of information whether we're immediately calling our callback, or doing it later on. + +{{}} +Update your backend to support long-polling. + +You may want to make this an optional behaviour (e.g. by adding a command line flag, or allowing a client to opt in to fast- or long-polling based on a query parameter) so that you can easily experiment with both. +{{}} diff --git a/common-content/en/module/decomposition/making-chat-live/index.md b/common-content/en/module/decomposition/making-chat-live/index.md deleted file mode 100644 index a2ac8affd..000000000 --- a/common-content/en/module/decomposition/making-chat-live/index.md +++ /dev/null @@ -1,12 +0,0 @@ -+++ -title = "Making chat live" -headless = true -time = 30 -facilitation = false -emoji= "📖" -[objectives] - 1="Implement long-polling in a backend to get notifications of new data" - 2="Implement long-polling in a frontend to display new data without requiring user intervention" -+++ - -### Making chat live diff --git a/common-content/en/module/decomposition/non-live-chat-application/index.md b/common-content/en/module/decomposition/non-live-chat-application/index.md index 1781894e4..cbc6233db 100644 --- a/common-content/en/module/decomposition/non-live-chat-application/index.md +++ b/common-content/en/module/decomposition/non-live-chat-application/index.md @@ -1,13 +1,36 @@ +++ title = "Making a non-live chat application" headless = true -time = 30 +time = 60 facilitation = false -emoji= "📖" -[objectives] - 1="Write and run a frontend, backend, and database" - 2="Persist data passed from a user into a database" - 3="Display data from a database to a user" +emoji= "🚧" +objectives = [ + "Write and run a frontend and backend", + "Store data passed from a user into a backend", + "Display data from a backend to a user", +] +++ -### Making a non-live chat application +{{}} +Write a frontend and backend for our chat application. + +Remember, the two requirements we have to start with are: +1. As a user, I can send add a message to the chat. +2. As a user, when I open the chat I see the messages that have been sent by any user. + +But soon we'll be adding: + +3. As a user, when someone sends a message, it gets added to what I see. +4. As a user, I can "like" or "dislike" someone's message. +5. When messages are liked or disliked, a count of the likes and dislikes is displayed next to the message. + +It's useful to remember what we're going to do next - it may impact how we do things now. + +But for now, our _main_ focus should be our two first requirements. +{{}} + +{{}} +Run your frontend and backend together locally. + +Test that it works as we expect. Send several messages. Refresh the page. Make sure you see all of the message (in the correct order). +{{}} diff --git a/common-content/en/module/decomposition/repeated-client-requests-for-updates/index.md b/common-content/en/module/decomposition/repeated-client-requests-for-updates/index.md new file mode 100644 index 000000000..e3ab9bd04 --- /dev/null +++ b/common-content/en/module/decomposition/repeated-client-requests-for-updates/index.md @@ -0,0 +1,45 @@ ++++ +title = "Repeated client requests for updates" +headless = true +time = 90 +facilitation = false +emoji= "🔄" +objectives = [ + "Stream live updates from a server by using repeated HTTP polling.", +] ++++ + +First let's explore how the client can remember "since when". + +{{}} +Teach your backend how to answer "since when" queries. + +You can choose whether you want to use array indexes, timestamps in objects, or some other "since when" tracker. + +You can also choose whether you want this to be the same endpoint as your "get all messages" endpoint (with some query parameter), or a separate endpoint. +{{}} + +Now that our backend can answer the question "show me messages since", we can update our frontend to repeatedly ask for new messages, and add them to the UI. + +Here is an example function we could write to do this: + +```js +const keepFetchingMessages = async () => { + const lastMessageTime = state.messages.length > 0 ? state.messages[state.messages.length - 1].timestamp : null; + const queryString = lastMessageTime ? `?since=${lastMessageTime}` : ""; + const url = `${server}/messages${queryString}`; + const rawResponse = await fetch(url); + const response = await rawResponse.json(); + state.messages.push(...response); + render(); + setTimeout(keepFetchingMessages, 100); +} +``` + +It asks for messages since the last seen message (or all messages, if we don't know about any), updates the known messages state, re-renders the page, and then calls itself in 100ms. + +This means that within about 100ms of a message being sent, we should know about it and display it. + +We only transfer new messages, we're not sending all messages over the network every 100ms. That would be a lot of data. + +But we _are_ making a lot of requests. Probably most of those requests get an empty response. And this is in its own way expensive - making a new HTTP connection over and over again takes some compute and network resources. And each time we make a request, our server has to do some work to work out how it should answer. diff --git a/common-content/en/module/decomposition/single-request-response-limitations/index.md b/common-content/en/module/decomposition/single-request-response-limitations/index.md new file mode 100644 index 000000000..04f402637 --- /dev/null +++ b/common-content/en/module/decomposition/single-request-response-limitations/index.md @@ -0,0 +1,53 @@ ++++ +title = "Limitations of a single request/response" +headless = true +time = 30 +facilitation = false +emoji= "✋" +objectives = [ + "Identify the limitations of loading a website via a single request and response.", + "Give examples of functionality that relies on subsequent data transfer from the server to the client.", + "Identify and explain why clients typically initiate requests.", +] ++++ + +HTTP is a single-request/single-response protocol. + +A client makes a single request, and a server sends a single response. + +This leaves no room for updates. In our chat example, we made a request, and the server could tell us all of the messages it knew about when it responded. + +If a new message comes in, the server has no way of telling us about it. It already sent its response. + +We can imagine a few ways to overcome this limitation, for example: +1. The client could also the server again. +2. We could use something _other_ than an HTTP request which allows multiple responses, or bi-directional communication. +3. The client could ask the server to make an HTTP request to it if there are new updates. + +### Limitations of an un-addressable client + +The client probably can't ask the server to make an HTTP request to it if there are new updates. + +This would effectively ask the client to act as a server, and the server to act as a client. + +This is possible! One program can be both a client and a server. + +But it is difficult, because to make a connection to a server we need to know an address for it. And most computers running web browsers don't have a public address other computers can use to access them. + +If it did have a public address, the client would also need to reserve a port so that when an HTTP request came into the computer, the operating system would know how to give it to the right web-page. + +Most web browsers don't have an API for reserving a port and sending a publicly accessible address+port to a server, so we probably can't do this. + +### Overcoming these limitations + +We've seen that asking the server to make an HTTP request to the client is hard. Let's explore the other two options we mentioned. + +#### The client could ask the server again + +We've seen that the server can't just send a response to the client without a request. But a frontend can do things after a page first loads. The frontend could ask the backend for any new messages. + +#### The client and server could set up bi-directional communication separate from HTTP request/response pairs + +Most Web browsers support [the WebSocket API](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API), which allows bi-directional communication. + +We will try out both of these solutions. diff --git a/common-content/en/module/decomposition/websockets/index.md b/common-content/en/module/decomposition/websockets/index.md new file mode 100644 index 000000000..c5b94d293 --- /dev/null +++ b/common-content/en/module/decomposition/websockets/index.md @@ -0,0 +1,116 @@ ++++ +title = "WebSockets" +headless = true +time = 120 +facilitation = false +emoji= "🔌" +objectives = [ + "Stream live updates from a server using WebSockets.", + "Discuss the trade-offs of using WebSockets or polling.", + "Describe properties of message formats (e.g. including a command name).", +] ++++ + +WebSockets are an API and protocol which allow creating a bi-directional communication channel between two programs. + +They are commonly used in websites to establish a channel so that a backend can send updates to a frontend. + +You can read [an introduction to WebSockets](https://docs.developer.tech.gov.sg/docs/data-engineering-initiative-playbook/Chapter5/Introduction_to_WebSockets), as well as roughly [what a client looks like](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications), and [what a server does](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers). + +On the server side, we will be using the [websocket npm package](https://www.npmjs.com/package/websocket) which lists a server example in its README. + +> [!TIP] +> +> This sprint, you will need to submit _both_ a copy of your code which supports polling, _and_ a copy which supports WebSockets. +> +> You probably want to make a copy of your polling code, and have two separate (similar) pages in your repo. + +On the backend, you can create a WebSocket server by adding this code: + +```js +import { server as WebSocketServer } from "websocket"; +const server = http.createServer(app); +const webSocketServer = new WebSocketServer({ httpServer: server }); +``` + +You will then need to follow the example in the `websocket` npm package's documentation to have your server handle requests. + +On the client-side, you will need to make a new `WebSocket` connection to the server. + +Some things to think about when implementing WebSockets updates: + +### Learn new APIs in isolation + +It will be easier for you to learn a new API (like WebSockets) with a simple example. + +At the end, you will want your WebSocket to stream new messages from the server to the client, but maybe to explore WebSockets you want the server to always report the message "Hello" when it's connected to, so you can test things out more easily? Or even write a whole new website which _only_ makes a WebSocket connection and displays a message? + +Once you have an example WebSocket working, and understand how it works, it should be easier for you to apply that to the real problem you're trying to solve. + +### Think about the protocol you want + +WebSockets let you send arbitrary text (or binary) messages. + +In our quote server, we switched from our backend returning a pre-formatted string of a quote, to returning a JSON object so we could get the parts ourselves. + +Think about what structure would be useful for our client and our server to know about. + +If we're going to add more messages in the future (e.g. for "liking" a message), how will the receiver of the message know what kind of message the one it receives is? + +One thing we often do is wrap our message in an object, with a field specifically saying what the command is. + +e.g. instead of sending: +```json +{ + "user": "Azin", + "message": "Hello!" +} +``` + +we may send: + +```json +{ + "command": "send-message", + "message": { + "user": "Azin", + "message": "Hello!" + } +} +``` + +This means that if we add new commands in the future, we don't need to change our existing code. + +### Think about timings + +When we first load a page, we need to get all of the messages that already exist. + +After that, we can ask to be notified of new messages. + +There are a few ways we could do that. An interesting question is what happens _between_ these events? + +Imagine we made an HTTP GET request to ask for all of the messages, then created a WebSocket to get new messages. What happens if someone sent a message between when we got our response, and when the WebSocket was connected? How can we make sure we don't miss any messages? + +Or imagine we made a WebSocket request, and expected to receive a list of all previous messages, and then to keep receiving updates. Does the server need to remember which messages have already been sent to each client? + +{{}} +Write down your strategy for how to make sure that after initially getting the existing messages, your client won't miss any new messages. +{{}} + +### Remember WebSockets are bi-directional + +Now, we're using a `POST` request to send a new message, and a `WebSocket` to stream receiving new messages. + +But we know that WebSockets are bi-directional - we can both send and receive information on them. + +We could change our sending logic to also use our WebSocket. Or we could keep using HTTP POST requests. Both of these approaches work. + +{{}} +Think: What advantages does each approach have? + +Why might we want to change our implementation to use a WebSocket for sending messages? + +Why might we want to keep using POST requests for sending messages? + +Why might we want to support _both_ on our server? Why might we only want to support one on our server? +{{}} diff --git a/org-cyf-sdc/content/decomposition/sprints/2/backlog/index.md b/org-cyf-sdc/content/decomposition/sprints/2/backlog/index.md index d23d2978e..536c622f8 100644 --- a/org-cyf-sdc/content/decomposition/sprints/2/backlog/index.md +++ b/org-cyf-sdc/content/decomposition/sprints/2/backlog/index.md @@ -4,6 +4,6 @@ layout = 'backlog' emoji= '🥞' menu_level = ['sprint'] weight = 2 -backlog= 'Module-Template' -backlog_filter='📅 Sprint 1' +backlog= 'Module-Decomposition' +backlog_filter='📅 Sprint 2' +++ diff --git a/org-cyf-sdc/content/decomposition/sprints/2/prep/index.md b/org-cyf-sdc/content/decomposition/sprints/2/prep/index.md index f4c20887f..dda018fb5 100644 --- a/org-cyf-sdc/content/decomposition/sprints/2/prep/index.md +++ b/org-cyf-sdc/content/decomposition/sprints/2/prep/index.md @@ -6,18 +6,30 @@ emoji= '🧑🏾‍💻' menu_level = ['sprint'] weight = 1 [[blocks]] -title="Read about the world-wide web" -src="module/decomposition/read-about-the-www" +name = "Chat application requirements" +src = "module/decomposition/chat-application-requirements" [[blocks]] -title = "Making a non-live chat application" +name = "Making a non-live chat application" src = "module/decomposition/non-live-chat-application" [[blocks]] -title = "Deploying the chat application" +name = "Deploying the chat application" src = "module/decomposition/deploy-chat-application" [[blocks]] -title = "Long-polling requests" -src = "module/decomposition/long-polling-requests" +name = "Limitations of a single request/response" +src = "module/decomposition/single-request-response-limitations" [[blocks]] -title = "Making chat live" -src = "module/decomposition/making-chat-live" +name = "Designing a streaming API" +src = "module/decomposition/designing-streaming-api" +[[blocks]] +name = "Repeated client requests for updates" +src = "module/decomposition/repeated-client-requests-for-updates" +[[blocks]] +name = "Long-polling" +src = "module/decomposition/long-polling" +[[blocks]] +name = "Websockets" +src = "module/decomposition/websockets" +[[blocks]] +name = "Adding like/dislike" +src = "module/decomposition/adding-like-dislike" +++