WEBVTT 1 00:00:01.200 --> 00:00:07.073 The client-server model is the first pattern you must embrace to build for the web. 2 00:00:07.273 --> 00:00:09.361 The idea is simple. 3 00:00:09.386 --> 00:00:10.826 A client asks. 4 00:00:10.826 --> 00:00:12.472 A server answers. 5 00:00:12.776 --> 00:00:17.883 This transaction is typically conducted over a network. 6 00:00:18.082 --> 00:00:22.840 Let's explore the pattern now, starting with the client. 7 00:00:23.541 --> 00:00:37.030 A person uses a device, a laptop, a phone, a tablet, a screen reader, to request a URL over HTTP, usually with a browser like Chrome. 8 00:00:37.230 --> 00:00:41.895 Sometimes the browser hides inside a mobile app, as a webview. 9 00:00:42.199 --> 00:00:45.936 Sometimes there's no person at all, just a script. 10 00:00:46.135 --> 00:00:53.633 With so many combinations of hardware and software, we call whatever makes the request the user-agent. 11 00:00:53.833 --> 00:00:59.311 Fun fact: user-agent is a combination of user and agent. 12 00:00:59.615 --> 00:01:06.207 From the start, the web expected both people and software agents to make requests. 13 00:01:06.408 --> 00:01:21.987 Bots, crawlers, and agents were early citizens of the web alongside human users and they had conventions for how they should behave such as respecting the robots.txt file on a site. 14 00:01:22.187 --> 00:01:26.852 The conventions of old sadly have been lost to many of today's developers. 15 00:01:27.063 --> 00:01:41.457 Right now, we can easily see both agents do real harm, like hacking attacks or mass content extraction, and do good, helping people get things done efficiently without abusing resources. 16 00:01:41.668 --> 00:01:46.403 The split here is not the agents; it's their operators. 17 00:01:47.103 --> 00:01:57.480 The user-agent sends its HTTP request across the internet for a public site, or across a local network for an internal, intranet app. 18 00:01:57.681 --> 00:02:03.461 That network, and its conditions, shape everything that follows. 19 00:02:03.660 --> 00:02:06.921 Careful, here comes a classic mistake. 20 00:02:07.131 --> 00:02:12.969 We build and test almost entirely on our own machines. 21 00:02:13.170 --> 00:02:17.220 On your own machine, the network disappears. 22 00:02:17.303 --> 00:02:27.216 Bandwidth is nearly infinite, latency is nearly zero, and the device behaves exactly as you expect. 23 00:02:27.416 --> 00:02:33.393 Thinking your laptop and load conditions are the real world is dubbed the localhost effect. 24 00:02:33.534 --> 00:02:38.386 Always guard against the tempting illusion the localhost effect presents. 25 00:02:38.469 --> 00:02:45.410 Its world is an ideal world that hides much of the web's variability and hostility. 26 00:02:45.610 --> 00:02:49.172 Remember the law: you are not the user. 27 00:02:49.383 --> 00:02:55.244 Your device isn't their device, and your network isn't their network. 28 00:02:55.944 --> 00:03:03.303 Eventually the request reaches a host running a web server, such as Apache or Nginx. 29 00:03:03.386 --> 00:03:09.247 It speaks HTTP too, and it tries to fulfill the request. 30 00:03:09.447 --> 00:03:16.713 Sometimes that means returning a file named by the URL: the web of documents. 31 00:03:16.913 --> 00:03:23.529 Sometimes it means running a program and returning the result: the web of applications. 32 00:03:23.729 --> 00:03:30.949 Real systems blur the line, but a request is generally either fetching an asset or running code. 33 00:03:31.149 --> 00:03:35.723 Fun fact: the industry calls some hosting approach serverless. 34 00:03:35.723 --> 00:03:37.881 That technically makes no sense. 35 00:03:37.906 --> 00:03:40.133 There is always a server. 36 00:03:40.333 --> 00:03:47.042 The term likely comes from platforms that hide the server so you can just upload a cloud function. 37 00:03:47.345 --> 00:03:53.927 Hiding the presence of a server doesn't make it go away, and it breeds misunderstanding. 38 00:03:54.231 --> 00:04:06.036 Even worse, the convenience of not thinking about a server can also mean you give up some control, which is one of the benefits of the client-server model. 39 00:04:06.235 --> 00:04:14.685 Finally, to complete the pattern, the response travels back, and the client uses it, often by showing an HTML page. 40 00:04:14.954 --> 00:04:24.229 URL, HTTP, and HTML: the three core web technologies, together in one conversation. 41 00:04:24.929 --> 00:04:30.105 Now back to the network, because it shapes the entire conversation. 42 00:04:30.305 --> 00:04:37.025 If the user is far away, a request takes a long time to go and come back. 43 00:04:37.236 --> 00:04:44.630 If the network is congested, by an outage or a rush of viral traffic, it takes longer still. 44 00:04:44.830 --> 00:04:48.892 That delay between cause and effect is latency. 45 00:04:48.917 --> 00:04:55.997 Gamers know it as lag, the thing we blame for our losses instead of our gameplay. 46 00:04:56.197 --> 00:05:02.581 We measure latency in milliseconds, and we want it low and steady. 47 00:05:02.781 --> 00:05:08.189 Fun fact: the internet and its protocols were built to route around trouble. 48 00:05:08.261 --> 00:05:11.405 If one path fails, packets find another. 49 00:05:11.535 --> 00:05:14.494 What they can't route around is distance. 50 00:05:14.507 --> 00:05:19.567 Lag, so to speak, may be intrinsic and by design! 51 00:05:19.767 --> 00:05:24.258 Some latency is physics, and no next version will fix it. 52 00:05:24.399 --> 00:05:31.213 Reach a server in California from Antarctica by satellite, and web apps can become unusable. 53 00:05:31.423 --> 00:05:34.187 Our film Engineering for the Extreme? 54 00:05:34.187 --> 00:05:36.321 tells that story. 55 00:05:36.521 --> 00:05:42.347 Other latency comes from congestion, simply more traffic than capacity. 56 00:05:42.558 --> 00:05:47.549 Fixing that runs into economics, where profit often wins. 57 00:05:47.748 --> 00:05:54.759 We're watching systems get worse even as technology improves, because the market lets worse cost more. 58 00:05:55.062 --> 00:05:59.194 There's a popular word for that: enshittification. 59 00:05:59.894 --> 00:06:03.723 Bandwidth is the rate at which data moves. 60 00:06:03.923 --> 00:06:05.187 Picture pipes. 61 00:06:05.212 --> 00:06:08.275 Water through a garden hose is constrained. 62 00:06:08.579 --> 00:06:12.060 A bigger pipe moves far more each second. 63 00:06:12.201 --> 00:06:15.183 A sewer main moves a torrent. 64 00:06:15.383 --> 00:06:17.181 Networks are the same. 65 00:06:17.484 --> 00:06:25.714 We count bits per second: 10 Mbps, or, if you're lucky, 10 Gbps. 66 00:06:25.914 --> 00:06:30.161 For most of the web, though, latency is the tighter limit. 67 00:06:30.245 --> 00:06:35.920 Unless you're sending large media like video, you don't need much bandwidth. 68 00:06:36.120 --> 00:06:42.364 Sadly, developers waste bytes, turning a non-problem into a problem. 69 00:06:42.565 --> 00:06:50.388 Fun fact: the median web page keeps growing, yet pages don't do much more than they used to. 70 00:06:50.692 --> 00:06:55.706 The bloat comes mostly from JavaScript frameworks and unoptimized media. 71 00:06:56.009 --> 00:07:07.420 You can verify this fact by looking at the data collected in the HTTP Archive, which has broadly studied web characteristics for well over 10 years. 72 00:07:07.631 --> 00:07:19.738 The failure to respect the web medium is sadly less of a negative opinion and more an observed fact if you bother to look or consider things from the user's perspective. 73 00:07:19.938 --> 00:07:27.552 To help you tame resource abuse, consider measuring your page in floppy disks, about a megabyte each. 74 00:07:27.635 --> 00:07:31.964 Whole applications, even games, once fit on one. 75 00:07:32.175 --> 00:07:35.192 Your web page shouldn't come close. 76 00:07:35.891 --> 00:07:41.067 So there's delivery time in theory, and delivery time in practice. 77 00:07:41.268 --> 00:07:46.769 We influence it by how we build: how many bytes, and how they're organized. 78 00:07:47.073 --> 00:07:52.528 But the actual time depends on the user and the network. 79 00:07:52.727 --> 00:07:58.716 The network, and as we'll see, the client, are simply not under our control. 80 00:07:58.927 --> 00:08:02.640 A perfect solution is impossible here. 81 00:08:02.841 --> 00:08:10.711 Engineering, web or otherwise, accepts solutions within tolerances, not perfection. 82 00:08:10.910 --> 00:08:23.517 To keep that in mind, the Professor offers a golden rule, his Performance Law: send less data, less often, from nearby, and only when needed. 83 00:08:23.717 --> 00:08:30.101 Less data: minimize what you send, and compress what you must. 84 00:08:30.300 --> 00:08:37.102 Less often: reuse what you've already sent, through caching or installed assets. 85 00:08:37.302 --> 00:08:40.400 From nearby: respect latency. 86 00:08:40.483 --> 00:08:47.633 Work on the device, local-first, or use a content delivery network to shorten the trip. 87 00:08:47.833 --> 00:08:58.071 Only when needed: don't fetch bytes too early, like aggressive pre-caching, or too late, when the user notices the wait. 88 00:08:58.271 --> 00:09:05.734 So instead of uploading code and hoping, we accept the network, optimize for it, and measure. 89 00:09:06.247 --> 00:09:13.896 Google's RAIL model is our goal, and our film A Budget for Patience shows how to use it. 90 00:09:14.596 --> 00:09:20.469 The client side has the same control problem as the network, and worse. 91 00:09:20.669 --> 00:09:34.855 As we saw with user diversity, we can't count on the device, the display, the processor, or the connection, let alone the person's abilities and expectations. 92 00:09:35.055 --> 00:09:40.997 You can't guarantee what happens there, and you can't truly secure what you send there. 93 00:09:41.394 --> 00:09:48.915 Yet that's where our content and apps must go, because it's the only place we get real responsiveness. 94 00:09:49.115 --> 00:09:55.592 The client side: nearly impossible to control, but it's relatively quite fast. 95 00:09:55.792 --> 00:09:58.555 The server side is the inverse. 96 00:09:58.555 --> 00:10:02.652 You run it, so you can control it and, hopefully, secure it. 97 00:10:02.955 --> 00:10:09.374 You pay for this control with speed, because every answer crosses the network. 98 00:10:09.573 --> 00:10:18.708 On a fast, controlled network, you might build a thin client: the client only displays, and the server does everything. 99 00:10:19.105 --> 00:10:23.573 Today's internet doesn't let us assume that network. 100 00:10:23.773 --> 00:10:32.142 Flip it, and you get a fat client, with most of the logic in client code, as in many single-page apps. 101 00:10:32.283 --> 00:10:37.308 Given how varied devices and situations are, that's often brittle. 102 00:10:37.450 --> 00:10:43.624 It may work for you, but make sure to measure whether it works for your users. 103 00:10:43.824 --> 00:10:51.996 Extremes of client or server only suit the cases where security or performance outweighs everything else. 104 00:10:52.137 --> 00:10:54.852 Most systems are hybrids. 105 00:10:55.052 --> 00:11:01.111 Choose the balance for your software and its users, not for the fashion of the moment. 106 00:11:01.311 --> 00:11:08.914 Many web failures come from rebuilding the browser, or the web itself, instead of working with the medium. 107 00:11:09.217 --> 00:11:19.119 The course will encourage you to often employ the design philosophy called Progressive enhancement to help mitigate many problems. 108 00:11:19.818 --> 00:11:30.010 So: a client asks, a network carries, a server answers, and much of it is outside your control. 109 00:11:30.210 --> 00:11:32.588 Beware the localhost effect. 110 00:11:32.613 --> 00:11:35.305 Respect latency and bandwidth. 111 00:11:35.330 --> 00:11:37.569 Follow the Performance Law. 112 00:11:37.769 --> 00:11:43.874 And tread carefully with architecture until you understand your users and your problem.