Transcript

We've built devise for a non technical audience.

But as we have helped now hundreds of people build applications on our platform,

we've realized that there are a few basic principles and just understanding about how the web works that has helped people to build better apps that are more performant and pick up device much faster.

So the purpose of this video is for me to teach you.

Again,

this isn't going to be a computer science class,

but just a basic understanding of how the web works and how some of these different pieces that you may have heard about and maybe didn't really understand fit together.

It's not going to be super in depth.

We're not going to cover every edge case.

But again the goal is to help you just gain a little bit better understanding of how the web works and hopefully help you build better applications.

Okay,

so I've built a few diagrams to help us.

This is where we're going to start.

you might have heard this called like a client server relationship.

Let's not use any technical terms here.

And the only reason I use some technical terms is just so that it may fill in some gaps like words you may have heard before.

But essentially and if someone technical is watching this,

they're going to have a fit and say oh,

you didn't cover X,

Y and Z.

I know I didn't cover every single edge case.

But we are and go into detail and I've oversimplified a lot of it.

This isn't about getting things necessarily to be 100% correct as much as it is having the right intuition about what is happening.

So hopefully this will be helpful.

So all of us are familiar with using a web browser.

Here's this,

which I'm representing by this home screen of Google,

right?

This,

this is my tab over here Google.

and we are all familiar that I can go to Google,

I can type google.com and this page loads well what's actually happening?

Okay,

so backing every website is what we'll call a server.

And the URL that we put in,

which we've all seen starts with HTTP.

Okay,

so I'm putting google.com what's happening is this is sending a request over to the server.

The server is going to handle some logic and then it's going to send the response back and we can actually see this happening.

If I go to a page and I click inspect,

you can go to a.

Right.

So this is like the developer tool of the browser.

I can go to the network tab and if I reload we can See,

ignore all these other ones.

This first one was made a request to the URL.

Google.com,

we'll go through some of these items.

Okay,

so we'll go into more detail about what your server does.

But then connected to a server is your database.

So your database,

you may have.

There's lots of different varieties of databases.

You might have heard of ones called Postgres and MySQL or Firestore or MongoDB.

The server talks to the database.

Let's think about an app like Facebook or something where you get posts.

You type in facebook.com,

it takes you to the profile page.

All these posts load.

The browser makes a request to the server.

The server has all this code that outlines the logic.

In plain English,

we would say it's like,

first check and make sure the user is logged in.

Then let's go get all the posts that are relevant to the user.

Then let's write the HTML that has all these posts into it and then let's return all of it to the browser.

The server is what talks directly to the database.

I think part of what's confusing is there's a lot of cool technology that have come out today.

If anyone has experience,

a basic experience trying to build apps where to them it's felt like they were able to connect to their database directly from the browser.

And that is what that technology is designed to do,

is to help you feel like that's what happened.

But it still went through a server.

Your browser went through a server,

typed into the database.

The database went back to server,

came back to your browser.

Then the last thing I'll call out,

because people tend to have these questions all the time about misunderstanding languages,

the browser and again the same relationship could work for a mobile app and different things.

We're just going to focus on the web for now.

The browser really only understands HTML,

CSS and JavaScript.

There's technically a separate conversation I can have about WASM and all these other things.

We're going to ignore that for right now.

HTML,

CSS,

JavaScript.

So if you hear people about like,

oh,

I built an app and all these different,

you know,

all these different languages,

maybe some of the ones I've listed over here,

they're not talking about the like,

front end,

the ui,

what Actually the code that runs in the browser,

that can only be HTML,

CSS and JavaScript.

The part they're talking about is the server.

Again,

I could write my server in.

I could Write it in JavaScript.

You might have heard Node Node is a runtime that allows you to write your server in JavaScript.

You might have heard of Python.

There's some frameworks called Django or a few others that are popular.

Or there's thousands of languages you could write a server in.

The server has all the code to when a request comes in.

Kind of like we talked about Facebook.

All right,

is the user logged in?

do I like,

you know,

let's go get the post for that user.

Like there's lots of different things that a,

you know,

server handles.

All of the business logic to handle the request when it comes in from the browser.

Requests come,

not just when the user hits enter on a URL.

New requests can happen.

When I click a button in my app,

you can have your front end code go and make requests.

like think about Facebook.

When I make a post,

your page doesn't reload,

but it's going to make a request to your server and your server will handle that logic.

We'll get into that.

So you can see right when I loaded Google think,

about 55 requests were sent just by load Google.

This can be stuff for analytics.

This could be images.

This could be loading the different parts of my app.

HTML,

CSS,

JavaScript.

There can be a lot going on here.

Let's double tap into these requests.

You may have heard some of these verbs before.

Like oh,

I made a post request,

a get request.

Okay,

so if we look at this request here,

it's saying,

all right,

the request URL,

it gave me this request method and it's called get.

There aren't hard and fast rules necessarily about the technology won't work if you use the wrong method.

It's more about best practices,

for which verbs to use often.

Get means I want to get something.

Let's pretend like some URLs here.

So let's say I have a URL that gets a,

you know,

that gets like when someone makes requests to my domain at slash books,

I want to return the list of books.

Okay,

well then let's say I want at the same URL I want to like.

If someone makes a request to books like I want,

how am I going to save a book?

Well that's where oftentimes it'll change the request method.

They'll say instead of a get request to books,

if I do a post request to books and I send some information about the title of the book,

the author,

then that will create a new book.

Again going up,

I may make a post request to my server to book book will Have a log,

say,

okay,

on a post request for books,

let's make sure that they sent us all the information we need.

Then let's go and make another request to our database to save that into the books.

The database will may return that value back and then we can return back a response to the browser that'll say that was successful,

you saved your book or no,

that didn't work.

Then another common one would be a put.

Let's pretend this was like to update a book,

you want to change the title of the book,

you entered it wrong,

you might do a put request.

The URL's a little different.

We're saying books.

And then this is a common way to designate a variable in a URL.

So let's say if I put the books and then I put the ID of that book as it's stored in my database again,

my server sent the information.

My server can validate that.

I'm allowed to do that.

Do any other logic it needs to do.

Go and update the database.

Database comes back.

This is the,

the loop that happens on a lot of these requests.

Another common question that people ask is,

all right,

in this whole process,

how do I keep track of the user?

Again,

there's lots and lots of ways to do it,

but I just wanted to highlight two,

cookies and headers are the most common way to store the user.

Again,

let's look at this request.

If we pull this out a little bit more,

you can see that,

I have this cookies here.

So cookies are a little way to store like a value on,

the user's computer.

So the like,

you know,

say,

let's go back to our Facebook example.

I make the request to say,

log me in and I send to Facebook my username and password.

They're going to,

you know,

validate that that was the correct username and password.

They'll look me up in the database,

do everything they need to do.

They're going to respond back and say,

yes,

that user is now logged in.

But they'll also attach to that request a cookie.

Specifically,

like saying create a new cookie.

The way it's set up is that your browser knows how to look for these cookies.

And so that if Facebook sends me a cookie,

it'll say,

okay,

I will save this locally,

literally on your computer or on your phone.

And then every time I now make a request to Facebook,

I'll include this cookie.

So the cookie could have like your email address or the ID of your user in their database so that every other request after that the browser will send this cookie to your server and your server can then get that cookie in addition to all the other information about your request.

And they can know who was logged in.

They can know like,

oh,

this request is coming from John,

or it's coming from Mark,

or it's coming from Amanda,

whoever this specific user is.

The other option is,

if you don't want to use a cookie is people can use tokens and you can use what are called headers.

So again,

you can see this tab headers.

So,

in the.

So when this request was sent to the Google server,

you can see here's a bunch of headers that were sent.

So headers are like not the main content of what you're sending,

but they're just like metadata,

extra information.

Think about like the header of a.

You know,

when you're writing a document,

probably in school,

where,

you know,

you'd have some paper on the Amazon Rainforest,

and at the top was nothing about the Amazon Rainforest.

It would say,

all right,

here's page one.

And maybe something like,

you know,

maybe it would include the title,

but it would also include like your teacher's name,

what section you were in,

yada,

yada,

yada.

Headers are kind of a similar thing.

When we're making requests.

It's not necessarily information specifically about the request,

you know,

nothing to do with the book,

but it's more metadata about maybe who the user is,

where the request is coming from,

what kind of device they're on.

There's lots of things that could be sent.

Lots of times when people want to do authentication,

instead of responding with a cookie,

when a user logs in,

they'll respond with the token the browser.

You can have your code save it.

Then every request you make,

you'll include a authentication header to tell the user.

The server can then read to know who is logged in.

These are all headers that were not necessarily sent with this request.

They're not the main content,

what was sent,

but they're a bunch of just metadata,

including cookies.

Go through header.

So you can see that when I made this request cookie,

here is the cookie that I've logged into Google.

I'm logged in.

Here's the cookie that Google sent to tell their server who the user was.

Then you can even see when they responded,

they responded with these,

responses can have headers too.

Here's the response headers.

They responded with this set cookie header.

Now there's going to be another cookie stored on my computer.

Classic Google.

Always trying to track what we're doing.

Hopefully some of these topics were not completely foreign.

Hopefully some of them made more sense.

But just again to recap,

the web basically works on requests.

Something like a web,

like a browser will make a request to a server,

the server will talk to a database and then the database will come back to server and then the server will complete the loop.

Sometimes we will use the same to connect to things that you might have called an API.

When we set up.

It's not just for getting HTML that can get returned.

Sometimes it might return something called JSON which is just a representation of data.

requests also can return image data.

You can see this request was to get the actual content of an image which right there I am.

but again when you are thinking about now coming back into devise,

when you're thinking about how building your app,

it's helpful to keep context on that.

some of the code,

like some of the things that you build in devise that code will run in your browser.

Other things that you build and devise that code will run on your server and it has interesting context.

technically anything you send to the browser the user has access to.

So you don't want to be leaking,

you don't want to be leaking secure tokens or information like things you don't want your user to know.

You don't want that to be in the code on your browser.

But if you're running it on your server and you have put in the right protections in place,

then it is appropriate.

That is the place where you can get secure information like maybe a token you're using to connect to Stripe to handle your payments or maybe like private information that only the logged in user should see.

You can load that data through the server.

Again,

hopefully this brief overview of how to build.

Again hopefully this brief overview of how the web works was helpful.

if there's anything else you want to add,

give me some feedback.

Happy to add some updates to this video.