All language subtitles for 005 Static vs Dynamic vs API_Downloadly.ir_en

In the previous lecture,

while talking about the front-end and the back-end,

I mentioned simple and static and dynamic websites,

or applications, a couple of times

but without really defining what they are.

So, in this video, I wanted to clarify these things

and also talk about APIs in order to bring

all these concepts into the bigger picture

of back-end web development in general.

So, let's start by talking about static

versus dynamic websites.

So, a static website, or a simple website

as I called it in the last video,

is when a developer uploads the final

ready to be served files of a website onto the web server.

These files usually contain HTML, CSS,

JavaScript, images, and more, and as I said,

these are the exact files that the server will later send

to the browser when the website is requested.

The browser will then take these files

and render them as they are.

This means that there is no work done on the server,

there is no back-end code, and there's also no application

whatsoever running.

Okay?

So, it's just a static web server serving static files,

exactly like I mentioned in the last video.

Now, you might think, wait,

when there is JavaScript on the page,

then there are usually dynamic effects,

like animations and stuff, right?

Well, that dynamic that you mean there

is a different dynamic.

It's just in the context of front-end development.

In the browser context, dynamic has nothing to do

with effects on a page or things moving around

but with the way websites are generated on servers.

Okay?

So, dynamic websites are different from static websites

because they are usually built on the server

each time a new request comes in.

So, like we saw in the last video,

dynamic websites usually contain a database,

then there's also an application running,

like a Node.js app, which fetches data from the database,

and then, together with a predefined template,

builds each page that the user requests dynamically

based on data coming from the database.

So, each time a browser requests a page,

that page is then built as HTML, CSS, and JavaScript files,

which will then be sent back to the browser.

This whole process is sometimes called

server-side rendering.

So, again, that's why it's called dynamic,

because the website can change all the time according

to the content that's in the database

or user's actions on the site.

For example, if you logged into Twitter,

it will show you a completely different page

than when you logged out, right?

And it will also show you a different page tomorrow

than it did today because there are new tweets,

so new data in the database.

And that is what dynamic websites are all about.

Now, if you, for example, go to Jonas.io,

and you should, by the way,

then you will always see the same content,

the same website, no matter when you visit

or what you do there.

And so, that means that it's a static page, all right?

Does this difference make sense?

Now, sometimes we use the term dynamic websites

and sometimes the term web application,

but they are kind of the same thing.

Usually when people refer to web applications,

they mean a dynamic website with some functionality

like logging in, creating user profiles,

searching for stuff, and things like that in general.

Websites are, for example, something like a WordPress blog.

They are still generated dynamically,

but we can't really do anything but reading them, right?

And traditionally, static and dynamic websites were the only

two types of websites, but in recent years,

thanks to how powerful browsers have become

on the client side, we see more and more websites

that are, basically, based on APIs.

So, let's learn how these work

and how we can use Node.js to power them.

Let's just keep the dynamic websites here in the slide

so that we can better compare the two.

So, just like with the dynamic websites,

we have a database here and we have an app

that fetches data from the database

each time a client makes a request, so in that sense,

an API-powered website is actually quite similar

to a dynamic website.

So, both work dynamically.

Now, the big difference here is that with an API,

we only send the data to the browser,

usually in the JSON data format,

and not the entire website.

So, again, just the data is sent to the client

and not the ready to be displayed website.

So, no HTML, no CSS, only the JSON data, all right?

So, when building API-powered websites,

there is always these two steps,

building an API and then consuming the API

on the client side, and by the way,

API stands for application programming interface,

and on a very high level, it's basically a piece

of software that can be used by another piece of software

to, basically, allow applications to talk to each other.

And we will talk a bit more deeply about

what an API actually is once we start building one.

Anyway, now about the client side I just mentioned.

So, this is where the website is then actually assembled

by plugging the data that we receive into some sort

of templates, usually using some fancy front-end framework

like React, Angular, or Vue.

I'm not gonna go into specifics here

because that would be for a front-end course,

but in very general terms, this is how it works.

So, you see that when builidng an API-powered website,

the building phase of the website kind of moved

from the back end to the front end, right?

Or we can also say it moved from the server to the client.

That's why many times you will see

dynamic websites being called server-side rendered

because they're actually built on the server.

On the other hand, API-powered websites are often

called client-side rendered, which makes sense, right?

So, for us back-end developers,

it's actually far easier to just build an API

and let the front-end people build a site, right?

And in fact, Node is an absolutely perfect tool

for building APIs, and it's very commonly used for that,

but of course, it's also perfectly suitable

to build a dynamic server-side rendered website.

So, in this course, we will actually do both versions,

starting with the API, and by the end of the course,

also building a rendered website using the exact same data.

I chose to do both because I believe it's extremely

important for you to know how to build both an API

and a server-side rendered website.

And now just to finish this video,

I wanted to quickly mention that the APIs

that we build with Node, or really, any other language,

can, of course, be consumed

by other clients than just the browser,

which is a huge advantage of building an API instead

of a server-side rendered website.

So, let's say we build an example API

on jonas.io/api/myCourseData.

So, whenever we hit that URL, the server will send back data

about the web development courses

that I am currently teaching.

Now, so far we only talked about requests

coming from web browsers, but we could also request

and then consume the exact same JSON data

on a native iOS app or an Android app,

or even on desktop apps for the Mac

or for Windows computers.

The possibilities are really endless when we build an API

because we simply have one data source,

which can then be requested and used anywhere,

not just browsers.

That's kind of the problem when we build a normal

dynamic website.

We return HTML and CSS and JavaScript files,

and only browsers can really understand these,

so we're then trapped into that single platform.

And that might not be a problem in many cases,

but for complex products that require a lot of apps

and then websites and web apps,

usually, an API is always needed.

So, in this example on Jonas.io, I could build this API

and then build an API-powered website and some apps

and get my data on all these clients

from just one source, all right?

And some people or teams don't even have any client

of their own at all and simply sell access

to their API to third parties

who will then consume these APIs and not their own.

So, there are really entire businesses

built around this philosophy of just selling an API

to other developers or companies.

Anyway, I hope that with this final slide the concept

and reason and, kind of, philosophy

behind building APIs now became crystal clear to you.

So, let's now move on.