Good morning, everyone.
Hello from campus.
I am right now in my lab here.
I just came in i think i
mentioned I'm in Ottawa for a little bit so
But just taking care of some businessing people.
But what I want, so today i want
The big thing is that we are sitting here with tutorial seven.
That is what we're going to talk about today.
Notice the deadlines on the tutorials.
We've moved them up because
Assignment three is due November 20th.
Assignment three is based on the code from
Tutorial seven. So I'll be putting that together the next day or two, but it's that code that's going on in
For assignment three.
So you want to get caught up in the tutorials and then so you're ready for working on the assignment.
So please…
do it as soon as possible. This is why you go to the tutorials
And you spend time there, then it's very easy to get checked off there.
If you go to office hours, they have to look more at your stuff and it does, but it takes time. And so you want to make sure you
aren't waiting until the last moment because you might not get seen in time.
Anyway, so…
A number of you have messaged me on Teams.
No.
Anyway, so I'm working on a lot of different things right now so
So I had a team that's email.
So I should be caught up by Saturday. If you don't hear from me by then, maybe try resending, but I'm planning on being caught up by the end of Saturday.
So that, so don't panic if I haven't replied to you. I know I got the messages.
Assignment.
And…
So I think that's all the administrative stuff.
Okay, so let's go on to talk about this code. So this code
This is basically a fixed up version
I made some changes, but the code that we were working on tuesday
I've fixed it up. So I want to do today now is kind of walk you through it.
Well, first I will run it.
It's always nice to see the code running and then we'll walk through it.
And…
So we have submit demo here. Let's go to here.
Okay. You know…
Pick up this here.
So here we've got this.
You can say upload a submission
So let's go here.
I don't know.
Is it fun.
didn't think I was coming in for class.
So here I've got this here, let's call this
Okay.
This one, I'm sorry.
So I've got, this is a test tutorial assignment. I've got this all here. Now let me put this in here. I'm going to mess up the format.
And let's go back to the browser. Let's try to upload a submission.
So I do this, I get an error.
So if I say upload.
Okay, that's a bug. That shouldn't happen. I thought I had made it so when…
wouldn't do that but anyway
That's a bug. They'll have part of the assignment fixing that bug.
But let's go over to
Let's see if that actually showed up here. So let's so list submissions.
That did get uploaded.
it just ignored question six.
Otherwise, it was fine.
And then we can go back home.
And we can say analyze submissions
And it says five records, student IDs. These are the ones. So there's five. There's one with a duplicate.
Here, which you can see if you list these
you can see there's two with this
One.
Did I fix the JSON sending? I definitely did fix the JSON sending.
And it's a really stupid fix when you see it.
So let's walk through the code here. So first off.
This code is very much
You know, uh.
DOM demo. It's really DOM demo plus the front end integration.
So the back end is
basically what we expected. But so let's focus on what's changed.
So we'll talk about list in a second. List has changed a little bit.
validator now contains all the stuff for validating the code.
That's all…
you know, this is oh
Oh, that's funny.
I should really change this. This is in tutorial six.
And I have this as tutorial six, but this is really supposed to be tutorial seven.
Oops. Okay, we'll fix that after class.
Just to make that because that's just irritating to me.
But so this is all load assignment. This is all things. But one thing I know, so we changed with load assignment is
if it gets this upload, if upload, then do upload submission
So that's the real change here. This is all
as we've had before.
upload submission here
gets the assignment file from my doc, get Allen from the assignment file from the HTM
And then it is load assignment true
And so that calls here and that ends up calling do load submission.
And so here we say sending data to server. So we just do a log.
And then if Q exists.
then we do this. So what's happening is Q is being something's being returned here
Thought.
I don't know why that…
have to see what's happening there. Anyway, this
Q is happening. We've got a request.
do our JSON here.
We've got our content application, JSON.
And then we do the fetch request. Then whenever that finishes, we say a request has 200,
Upload complete, else uploads like upload error with status or whatever the status
So this is all pretty straightforward. We're just using fetch. We have to use the then because fetch is asynchronous.
And we can't do an A weight here.
Because we're not in an asynchronous function. And you might think logically, why can't I just do it in a circle? Well, the key thing about a synchronous function is that it runs
Sure.
Sorry, did I get disconnected?
Seems like, yeah, what was that about?
What Wi-Fi am I on?
If it happens again, I'll have to switch Wi-Fis.
Anyway, let's…
Sorry about that.
Go here.
Let's go back here. So what was I saying?
Like, can you see my desktop?
Actually, no, you probably can't see my dust. I don't think that got.
Sure.
Okay, here we go.
Let's go back here and you all can…
You can see everything now.
Okay, so good.
So what I was saying is why can't you call Away inside of a regular function? Why do we have to do this then?
You know, this then syntax.
And the reason you have to do it is because regular functions must complete executing. They can't pause.
So you have to use this then so it will run
when the async task completes.
To upload submission is a synchronous function.
So what's going to happen here is it's going to run, run, run, run here. And then what it does is it will call fetch request.
And it will register
a callback for the promise because what's going to happen is fetch request will return a promise
And that promise will then pre-process by the then method.
And the then method.
will create a callback that will be, which is this function here, which will be called
when the promise is resolved.
So we have to
So that's what this function is. So this gets called this
function gets declared
But it doesn't execute now. The function will then terminate
It'll be done. It will return.
But…
what will then at some later point
When the response comes back from the server.
This anonymous function will be called and will process that response.
And then do the update tag and stuff.
Now, then is used for, so then is not a promise. Then is used to resolve
promises.
Okay, so I'll…
Yeah, so I'll tell you how he fixed it on the server side in a moment, how he fixed the JSON part. Actually adding the headers here.
This thing was just more doing it more properly
This is kind of the way you should do it, like specify the headers of what the type is that you're sending.
That's good practice, but this isn't strictly necessary if the server doesn't pay attention to it.
So…
So if you call in.
So if you're calling a function or method as asynchronous.
Remember, when we talk about asynchronous functions, asynchronous functions return promises.
And because it returns a promise.
you have to resolve the promise, which will be resolved at some point so
What it really means to resolve a promise is to say at some later point, this is the stuff you're going to do.
If you're talking about an asynchronous function, so let's go back
you know, it's remaining here. So like async handler here
When I call a weight file data path, in effect.
the rest of the function
is a callback function.
Because the moment you call await on this, this function
will pause operation.
It will pause and it will allow the dental runtime to do other things.
This code basically will not, but the rest of the function is basically put aside and said.
Run this.
after the promise that is returned by file data is resolved.
So that's what I'm saying. When you put async in a function, it really does change the semantics
of the function, because what will happen is to someone who calls it
it will return relatively quickly.
but it will return a promise.
And that promise, you have to resolve it. And you say, well, I'll just call A, wait, it'll be done. Well.
Calling a weight will cause your function to pause and basically turn it like this later stuff will get run so
When do you want to do this?
Basically, by declaring a function async, you're telling callers, this is going to return a promise. It's going to resolve at some point.
you got to handle that.
But if you're in a regular function.
like we are here
This function here, this function here is expected to complete normally. It's not async. And in fact, you can't declare async functions
Normally at the top level.
inside of like just client side JavaScript.
So
you have to use that to resolve that that fetch is async.
So to use it, it's going to return a promise
And so using this then method, we register
a callback to say, when the promise resolves, call this.
It's a little weird. It's a little weird to get your head around.
so some
So this goes for anything. If you look at your APIs, what's the…
So if you go to the deno file system APIs.
you'll notice that
all the…
So let's see.
they should all be so like open
Notice they're all asynchronous.
They all basically you know are
you know, their function you know their
They declared a thing they return a promise or something, but that's basically the same thing as declaring something async. Async is almost a shortcut for sync.
Dental then takes care of the promise to some degree.
But these are all asynchronous.
If you go to node.js.
Which is the older system.
And you go here and you look at these.
there is their synchronous, so the promises api
And they mentioned everything says fspromises.appen file
FS, you know, that's because this is the older API. The user one was
with a callback, you'd say FS access.
And you give the arguments, and then you give it a function to call
a callback when the operation resolves.
That's the way, the old way of doing things in
in JavaScript was, you know, do this and this is going to be asynchronous. So it's just you just give it a callback function and it'll call that callback function at some later time. You don't know.
Promises are essentially a way of getting the same semantics
but with much cleaner code.
And that's why when we're playing with Denno, they got rid of that whole callback stuff.
And they just did everything with promises.
So going back to our code here.
So now this is all client side. This is what's happening in the browser.
It's now sending sending data to the server with a post
to upload submission and the body of it, it's setting this, it's doing JSON stringify.
Q, which is the object here. By the way, this Q, I added, if you look at the code above, so it includes not just the questions.
but also the name and student ID.
So those are all now in that object.
But now we go back to the server.
And how is it going to handle this?
So first we got our handler
Handler has…
goes to route, route get post. So we got route post is what we want to look at.
So now I've changed route post to just handle upload submission.
Omicron's A08 add submission.
And so add submission here.
it does an a weight
for request.json.
In the old one, we had requests
dot form data.
So this is something I had to look up. It was like, how does Denno deal with forms? Turns out if you do Deno form data, that's if you're sending up
a standard form from a form element and it's formatted in that way, that's what will get to the sent to the server and this will, you know, form data will decode that streaming if necessary
Because it may be set up in multiple
bits. It'll get it all together decode it and
We'll give you back that.
Request JSON.
takes the body, assumes it's a JSON object.
parses that JSON, JSON object encoded in a string
And so it takes that string
following what JSON is and turns it into a JavaScript object.
And returns that. And that's what submission is.
So submission here
is exactly the same as q was
on the client.
And so then we just pass this on to add submission db
And, you know, and then, you know, response. And if we get a response that we say, otherwise we say there was a problem.
Wait that one more time.
So here, let's go back here we've got this
Where are we going here? So going down here to
So do upload submission. So remember we have upload submission
which is called by pressing the submit button.
That calls load assignment.
Load assignment, if it's called with true option, it will then call do upload assign upload submission with the file name that was used and the object, you know, all the questions, which actually is a full submission.
And so we take that
And then we go through this, use Q, and if it exists, we put it into a request.
We stringify it and then we send it to the server.
And then based on the response, we handle it.
So this is where the body of the
of the post is a JSON object.
So we go back now to the server.
And the server receives this
an ad submission. So first, you know, we get route post, upload the submission. We're just passing the request on.
This is where we actually do something with it. And we just do an AWait request.json. So it treats the body
of the, you know.
the request that came in
and turn it in, assume it's a json object
convert it to a JavaScript object and that submission. And then we process it on the server.
And we just add it to the database.
Why weren't we seeing anything when debugging the JSON data on the client and the server last class?
So as I understand it, so the question is, why did I have to call a weight here?
I mean, that's really what it comes down to.
I have an incoming request.
doesn't this have everything in it?
Well, it turns out when you get, in order to facilitate fast processing.
The quest that comes in here
doesn't necessarily have
the whole body of the post.
Because in general.
Posts can be very large.
Because you can upload large files to a web server using Post.
And so when you upload it to the server.
I'll have to like swipe this out so
Think.
So we have the request. Isn't the body just
part of their quest?
No.
So that's why we use these methods to go ahead and process that and it's going to be
potentially still streaming in.
So there might be a delay. That's why it's asynchronous. So it can handle these different cases.
Is it probably already on the server? Yes, in this case, because this is a small amount.
But it's set up so
even if it's larger, it can handle it.
So that's why so this
That's this a weight request.json. And that's why when we were debugging.
Can you use promises then in an async function? Oh, yes.
You can definitely use promises then inside of an async function.
But you normally wouldn't.
Because…
So if you're in an async function.
Use a weight because it makes your code much cleaner because then it reads like a sequential function, even though it's pausing and resuming and acting all these asynchronous ways, reading the code
is very clean. That's why async AWIT is a relatively recent, let me still
several years old at this point, but it's a relatively recent addition to JavaScript.
And it's something the community took some time over to figure out.
How can we make our code clean?
All right.
You couldn't follow the flow of control of the code very easily because it was callbacks inside of callback, there's a callback.
it gets messy. And so async gateways in general better way of doing things. It's just sometimes you can't because
you call it sync, you're in the middle of synchronous code and it's like, okay, I've got a promise
Here's a callback and the then syntax.
So when you use fetch and a function, does it take priority to other function, like even if it isn't first in chronological order?
It's not a question of taking priority.
What you're having here
is…
When you run a weight.
What it's really saying is everything after the rest of this function
is going to be paused. I don't know when it's going to be run.
But it's going to wait.
until whatever's coming back from request JSON
comes back and this is put on pause.
The Deno runtime
can do this a lot. You can have basically parts of JavaScript programs waiting around to be run
all over the place and dental will keep track of it. It's like, okay, that code's waiting to run, that code's waiting
Because if you think about it logically.
what's the web server potentially doing? It's going to wait
for some file IO data.
It's going to wait on network connected data from client one. It's going to wait on data from client two, it's going to be sending data on client three. It's doing lots of things
At the same time.
So.
So when we say many clients can connect, it's like
you can only take one at a time because of the network bandwidth and stuff. But effectively, you can be processing many requests at the same time because you're waiting for them to finish.
So when we say pause parts of the code waiting while other parts of the app keep running.
What do we mean here?
So we've got this. So think about this. We've got this handler function.
that gets requests.
How often can Handel get called?
Handler is going to be called
every time there's
an incoming request.
When one call to handler starts.
Does that mean that call has to finish
before it can handle the next rev request.
No.
Because what can happen is you can go here, this call function is called.
It gets a path name out, does this here, and then it calls a weight route.
So the moment it calls await route.
The rest of this code
is basically put on pause
And so this may finish at some later time. You don't know how long it's going to take, but then
A handler can be called again.
With another request that it goes here and calls a route and then it waits. And then another one, I mean, they could just stack this up. You could have potentially hundreds of requests.
sitting around waiting to be finished processing. And each of them are kind of going through the various steps
of handling a request at different rates.
And it doesn't matter all this interleaving of stuff is all handled by the Deno runtime.
And it just kind of, oh, I got this work to do. I've got this work to do. I got this work to do. And it just sort of
It finishes each one. None of the pieces interrupt each other.
So this is what says cooperative multitasking, different execution contexts pause
their work when they're waiting for data, but don't block the execution of other code in the app.
Now, contrast this
So if you want your code to do some useful operation
So you use threads or processes.
So, um.
Yes, there is P threads.
P threads, if you know about the P thread library
So the Pthread library in c um
allows you to do some concurrency. And so you can run multiple things at once but
So what we're really talking about here is how do we have a program do more than one thing at a time?
So really what the heart underneath the cooperative multitasking
of Denno is callback functions.
in a runtime that can
basically…
pause one and run other functions while that one's being paused.
And it switches. And because it
you don't have to worry about in dento
there's no arbitrary interleaving of code. We don't have to do things like.
you know, like we have some global data or something. We don't have to worry about, like, we can have arbitrary data in the globals here.
And we don't have to worry about locking it.
Because we know only one
It's only going to be executed one at a time. And when it's executing that whatever part of the application is running.
it's not going to be interrupted when it's not ready.
So you don't need locks.
It's very cool because locks are actually kind of expensive to implement.
When you take operating systems, you'll see more of this sort of thing. We talk about concurrency more, and you'll understand more about how
how computers share resources so they can do multiple things at once.
This is just a little
baby version of that.
So in the first web servers.
And…
So.
You'll cover threads and processes in um
operating systems. You don't really cover cooperative multitasking because it's not really an OS concept.
But you'll see how much complexity there is in operating systems
how you have a
This whole notion of processes and threads, how they're implemented
how the operating system shares data between them
Anyway, it's old thing. I teach that normally.
But it's important to realize
what's actually happening
with your Deno code.
it is doing multiple things at once, but it's doing so in a very
friendly way
In the sense of you can think about the code here as executing sequentially. It is executing sequentially
Only one thing's happening or the other. Nothing else is going to come in and mess with it. That's
like what happens if I have a variable or like if I have a global variable here
And two parts of my program tried changing them at the same time, and I can't decide which one was changing them and stuff. You get all kinds of weird values, especially
It's a more complex data structure.
Things go nuts.
So.
we don't have that.
in Deno
code.
And the reason we don't have that
Yeah.
So traditional IO
on every in every programming language.
the traditional way, like Python seeing stuff, it's all synchronous.
You do your code, you do the operation, and it finishes it. If you want anything to happen while you're doing that waiting.
you start another thread or you start another process.
And that's the way you do it. Asynchronous IO has been introduced to all these languages.
but they're not the standard way of doing things.
You can do it in all these other languages, those things, but it's not the default way of doing things.
This was the default with Node. This was the default with Deno because they were built with this in mind.
And all the APIs support it
And the entire runtime supports it. It's all built around this idea of making
fast web servers that do cooperative
that can basically handle
whole bunch of requests concurrently without resorting to using threads or proxies. It's one process, one single threaded process.
doing all this. Well, technically, it might not be multi single thread under the hood.
I think it might be multi-threaded under the hood but
as an application developer, as someone writing JavaScript
you never see this.
something that this is a little bit of digression, but not it's stuff I want to talk about. It's stuff that you have to really
have some sort of conceptual model about in order to understand
what's really happening.
in this code and being able to reason about it.
So, um.
So yeah, we talked about all that and that's
In fact, that covers everything.
If there are any more, I can go through other parts of this application, but again, it's like within the tutorial, you're going to see it all connect together
I will fix this tutorial 7 part. That's just annoying.
I'll change that after class, but…
But otherwise, you know, do the tutorial and you can have an assignment based on that
What I would like to do now, unless there's any other questions.
is talk about
to talk about authentication.
And stateful and statefulness, statelessness in HTTP. So we're getting a little more
conceptual, but this will be very important for the code we're going to start going through next week.
The reason we didn't so the reason we didn't, sorry, I thought I covered that. So the reason we didn't see json
on the server.
We saw JSON on the client.
The JSON showed up on the client no problem. The problem where we had was
So this, there was JSON here. We could see all that. That was all fine.
The problem we had is when we went to the server.
And we tried looking at the request here.
So in the equivalent of the upload submission here.
add some machinery. We'll go
what's going on here? Well, the reason why is I had requests
form data here.
And form data didn't work because it wasn't encoded as an html
TML form body data, like there's a certain encoding for that
it was encoded as a JSON object.
And so when I transform data on it, it just
got confused. And so that's why it blew up.
And then when I looked at it.
It's like, why don't I see the contents of that? Well, because
This thing is getting additional data. It's not in the request object itself.
So we'll look at the request object and the body's not there. It has to be gotten.
That's why we have to do an A white is because
It has to be gotten by another part of
the demo runtime. And that may require waiting on additional network traffic.
So it won't be there in the request object.
It might be there if this parses it and gets it there, then you get it out.
we hadn't, I was basically having to decode the wrong thing
So confused about the correct way to call fetch.
is only applicable to URL objects okay so
That's actually a great question.
So remember where we're
When we're in the browser.
We're doing…
HTML.
And so if I go here, this is
an HTML document.
I can, you know, you know, we can go here, we can view the source
This is the source. It's HTML. That's what we expect.
Now, if I go here and I go to my inspector.
I go to the network here, and I can see, and I go here and I say.
List submissions
you notice that list submission
caused a get request here.
to list. So this is doing
an HTTP request.
So we're all the time, whenever we link to something, include something, we're doing HP requests
the browser's handling it for us.
What fetch is doing
When we're talking about fetch here, we're talking about client side. Now, server-side JavaScript can do this as well, but it's then going to call another web server.
Fetch is an API.
that's used. And this is one reason why I really like deno
is because the fetch API is something that's available in the client. It's also available in Deno.
Anything that makes sense
any client-side code that makes sense on the server, you can do in Deno.
it's all standardized.
That's not quite the case in Node. You'll see little differences.
But, um.
So like here, let's look at this. So here we've got this
Oh, I didn't. So like here we've got another fetch so
The fetch here is getting
you know, fetching list
We're just saying fetch list. We're not doing anything else.
Because we want to do it as a get, working as default. We're not, you don't have to specify any body. We're just doing that URL. So we basically say fetch.
And this. And so what this causes
is a get request.
And we can use parameters to do a post request.
to a server. And this is just
some URL.
that's going, you know, and now there's turns out there are security restrictions on where you can do this. You can always do these requests to the server that gave you the web page.
you can't necessarily do this to arbitrary servers. That's part of security, and we'll talk about that. But if you're doing these
You can get data from the server you loaded the webpage.
So this is saying do an HP request. But what's different about doing fetch
is here.
you do these things, the data is correctly taken by the browser and used to render the page.
Here, Fetch does that request
takes the result takes the result
turns it into a response object
for client-side JavaScript.
to process.
And here what we're doing is saying like, if the response is okay
So this is like, you know, this is like we're just checking to see if it's okay
then we go
basically, I forget exactly what the okay
it's a flag that's set if
the response was correct. So basically, if you've got a 200, we don't have to check. This is a convenience instead of like checking what was
the status of it equal to 200. So we can just say, is it okay?
And if it's okay.
then we go
Here's table data.
table data is we a weight the response.json. So it's not in the response object, but we can use the response object
to get
you know, get it and then so this
turns it the JSON that was in there and turns it into a JavaScript object and assigns it to table. So that's what we're doing with fetch. We're doing
HTTP stuff.
to generally the originating server, you can do it to other servers under some controlled circumstances.
But instead of the data being used to directly render the page.
it's given to you in JavaScript for you to process so your JavaScript can then do things
to the page.
But fetch fundamentally is
you have to have a URL.
that you're doing it because fetch means go to a server
and do an HTTP request.
So this is a very simple form of fetch.
Here, we use a little bit more complicated one here
upload submission here it's post
we're turning the body into this. So this is because we're doing a more complicated one because we need to set the body
And that's something we really do with post
And then we specify the type here, application JSON.
So, but basically it's the same
Yeah, so this is all making a request object.
And then this request object is then used here.
As opposed to just using a string with a URL. There's a URL here, but there's a URL plus all this other stuff.
That's what the request object is.
If you just have a URL that goes like, oh, you just gave me a string. You didn't give me a request object.
I can, you know, now fiddle with this.
Think about this from a strictly typed
language perspective.
Fetch here is using
is taking an object.
Here, Fetch is taking
a string.
It's the same function.
Now, there are
like um
Like in Rust, you can make multiple versions of a function
that has the same name, but has different types
And it will…
like run different, it'll match which function matches the types and call that
That's not what's happening in JavaScript.
JavaScript, it just gets this
And the receiving function basically has this thing. It goes like, what is it? It goes like, is this a string? Oh, I'll do this.
is this kind of object?
do this. And if it's something else, oh, I got to throw an error
The problem with that is now your code has to really think about like it could be given any kind of data.
But the nice thing about it is you can have these clean APIs where you just
Sometimes I'll give it an object and they'll give a string. It makes it very clean in that sense.
I personally like this kind of flexibility, but I will agree that at scale it can cause problems because you don't have a compiler telling you that, oh, you called this wrong. You have to have a runtime error, which says, oh, look, you messed up. You gave this function some data, didn't understand.
Yeah. I don't really care. I don't mind runtime errors so much.
If you really care about runtime errors, you can have exception handling and have it.
deal with it but
Yeah, exactly. Yeah. You can add tests for that.
Exactly.
So, but…
Nadim, are you good now? Are you still confused about fetch can apply to URL objects?
So it's not your log and basically be a URL string or
a request object, and it might be able to take some other stuff.
Okay.
Python is kind of like this.
C is not, although C, you kind of get that when you start passing around void pointers.
where it has to fill things out, but JavaScript has a lot more support for just handling it.
I think…
strongly typed languages
have a lot of
benefits in terms of scaling up the teams that are working out because the tooling lets you detect errors
But…
I'll admit, I think clean, but I most want in my code is for it to be clean.
I want to be clear. I want to be able to understand what's going on and making APIs that
are semantically clean
I think it's much more important than making them syntactically clean.
So…
Personal preference. I think I learned less probably too early, but
That's me.
Yeah, so all this code, you know, I want to switch gears now
and talk about
Cookies.
You've all heard of cookies.
Uh.
I know you all know about them.
But I don't think you all understand
what they're really…
for and why they exist.
And it has to do with
So.
This is, I'm talking general level. When you talk about apis
APIs in general can be stateful or stateless.
And so a stateful API allows for small requests.
get approved forms for like caching, stateless APIs, however, can allow for greater parallelism.
Okay, talking very abstract.
what am I talking about?
scripter.
So what is…
So file API.
What am I talking about here if I do?
So a standard C library, here's open
So you open. This also is in like the C library version, but you open a file
You give it some flags and things. You give it a path name.
And then it returns an integer.
that integer that's returned
is a file descriptor.
That's a number. And then to read data from it.
you then use this. And you notice read
doesn't take a file name.
It takes a file descriptor.
this is number here. Now, you might say why
Why is it stateful like this?
So why do you have a stateful API?
It's because it can be useful for performance
Typically, you do the open once it does the work of figuring out where there's got this file name, where is it on disk?
Let me find it. Once I find it, let me not do that on every request.
I can now just say, okay, I've got that information saved. I can just do my reads and writes and whatever.
quickly and then put that saved state then has to be released
Okay, so that's a stateful API.
HTT, but…
Okay.
So HTTP, however, is a stateless protocol.
Every request is independent.
So this is very important, especially in the early days of the web because you
you got a lot of traffic, one computer wasn't enough to handle it all.
How do you deal with it? You just…
replicate that like if you think about replicating file API stuff and you have state
associated with like, okay, we have five servers, one of them's done the open, the other ones haven't done the open.
So you could take that request and make sure it goes to the one that already has the open
The other ones can't handle is they'll have to open it. They have to do the extra work. So it's just
that coordination
is a pain.
with staple servers and with stateless you just
replicate, do it, you're fine.
So we'll explain the cookies in a second here but
If you're just treating HTTP and HTML as they originally envisioned.
as things for serving hypertext documents.
things containing like scientific information just really
data to be read.
then the stateless model of HTTP was great because you have a high demand server
You just replicate the data
And then everyone, you know, it's, you know, copy the files between them. Anyone can access it. It doesn't matter
scales beautifully.
But the moment we want to do a web app, we probably have some state
i.e. things stored in a database, maybe some things associated with a particular user
like email or other things
what do we do then?
you know, we need to have some state
that's where cookies come in.
That's the basic idea of all this is the server sends some data to the client saying, hey, next time you talk to me.
give this to me and I'll know who you are.
So this is conceptually what's happening when we talk about cookies. And that's why cookies
are all over the web because it's a standard way of doing this. But you can
There's other standards. You can encode it in the url
But cookies are by far the most common thing, which is why the regulations on cookies and just having cookie banners on every website saying we use cookies.
is kind of dumb because there's cookies and there's cookies and it's like, what purpose are they being used for?
If you're using in the standard web app way, just to know, like, am I talking to the same client or not?
Okay, you've logged in.
So.
So that's why you have to use that state is maintained using things like cookies
I think I will stop there because after this, I'll need to start showing you how to use cookies and that we've got only three minutes left.
So I'm going to stop here unless there's any, and I'll just take questions.
on anything. Well, actually, I take that back. I can do something while we're waiting here.
We can go…
Finally, oh, oh, oh, that's a good point. The final exam
So you see this?
And you see all these kind of things here.
If you click on some of these requests, can we see the
Oh.
I should be able to see the cookies in some of these things. I'm just trying to see if I can…
This is image.
Let's upload here.
I'm here.
Oh, no, that's not what I'm…
Well, that's 8,000 requests for cookies, sorry.
And…
If you look inside the headers.
you see this header cookie
is accept connection live cookie and you have this data here
This is it sending a little bit of identification of service say hey
This is who I am. You sent this to me. I'm sending it back to you. This identifies me.
And you see it has all this stuff of last used here and stuff.
Oh yeah, you can see the cookies in the storage tab, but you can see it's in the request.
Where is the storage section? Oh, there it is here.
This is all the stuff that Wikipedia has stored in my browser.
related to this.
There's a lot of things.
Now, if I just go to here
This is Media Wiki. I can go to storage here
That's true.
there's even more.
Oh, it's probably because I'm logged in.
Because I'm not logged into a Wikipedia but look at
Just…
Oh.
So these are not all cookies related to homeostate. So these are the homeostasis specific cookies.
These other cookies are Carlton cookies.
that are related to, and we will explain why there's Carlton cookies and homeostasis.
cookies next time.
I will stop here.
Let's see.
Okay, good.
and um
Let's see if I can stop screen sharing.
Thank you very much. And I'll see you all Tuesday.
Simon 3 should be up very shortly.
And…
I will be answering all your questions
online.
Go have a cookie, okay?
Take care.