15 Fullstack Concepts Every Frontend Developer Should Know

Today, we're going to deep dive into 15 full stack concepts every front end developer should know to get to senior engineer. From low level concepts like IP, DNS, and HTTP, to high level architecture components, like API gateways and back ends for front ends. We'll also cover new web APIs, like servers and events, which are behind most modern AI applications. But first, let's start with the fundamentals.

HTTP, the Hypertext transfer protocol. So basically, HTTP is the underlying protocol that clients, in our case web browsers, use to communicate with servers. And so the first thing that the client does, the browser, it's an HTTP request. And that would be in this case a get request because it needs to get a resource. And the server will receive that over the network and basically start sending the index HTML file.

But how is that file sent to the client? Well, it's broken down into what we call TCP packages. These are as well data packages that move over the TCP protocol. And the client will take all those TCP packages and put them together in an HTTP response. Response code was 200, okay. And then it will look at the headers and it will basically realize that this is an HTML text and then start interpreting that and rendering the UI.

What is inside this TCP package? Package would have an IP header, which basically tells us data about what's inside and where this package has to go. And inside we have the data, the payload of the IP package. Well, that data, it's actually a TCP package, which has a TCP header again and the TCP payload. Our TCP payload is much smaller than the IP payload. The reason why we need a TCP header is because TCP has several advantages that IP doesn't have, which is that we get a guarantee as developers that there will be no package loss and that the packages will arrive in order.

And in order for the protocol to offer these guarantees, they need this extra place to add some information. And so if any package gets lost, we have retrying mechanisms at TCP level. And so we pay a bit of price in terms of size, but we get this guarantee from TCP. This TCP payload is basically chunks of data. And the easy thing you can think about this is as you would be reading from a file.

And so all these packages are then put together in what we call an HTTP response. The easiest way to think about an HTTP response, it's as a piece of text. The first line will indicate the overall status of that response, what is the 200 or 403, was the successful response or not. The second part will be the headers. And you can think of HTTP headers as data about the data. It will tell you the server it comes from, it will tell you the length, and what's inside, that would be the content type header.

In our case would be text/HTML. So then the browser starts rendering that. And then there would be an empty line and after the empty line, the data. And that will keep coming in, for example, in the case of HTML, and as the browser receives those HTML chunks, it will start rendering the webpage. So the easiest thing you can think about HTTP, it's as a system of letter sending, where you send a letter and then you receive one.

And on the brief, there is metadata, the headers, that tells you, okay, who's sending this letter and what's inside, and then inside of it, you have the data. Moving on to our second concept, DNS, the domain name server. DNS is basically a global system that matches a domain address with an IP address. And so going back to our client server model, DNS sits in the middle, because before a web browser makes any request to an IP address, it needs to know that IP address.

But, as humans, we don't want to go around memorizing IP addresses, they're pretty hard to memorize. Just plain numbers. So, instead, what DNS does, it gives us the ability to go in and type the Seniordev.com, and actually, they will match that to an IP. Now, all this happens under the hood and basically the browser will make a DNS lookup query. to request and it will go to the closest DNS server and basically ask, hey, what is the IP of this domain?

And if the domain is found, the DNS server has some tables and it will give them back that IP address. In this case, it's an IPV4 198.202.211.1. And now the browser will go ahead and actually make the HTTP request, make that get and get the file back. So, this happens before any kind of request if we make it to an actual domain name. And so if you go on a website and you type the domain name, you'll see that if you go over to the network tab and check the first request, the one that gets the HTML document, you'll see that there is a general information in the headers, and that is the remote address. That's what they call it.

And that's our remote address and you see that's an IP address and finally the https port because we move over https. And we'll talk about https also in this video. So, you can actually check this for any website you visit. In the end, everything on the internet happens with an internet protocol address, an IP address. And you might ask yourself, who is maintaining this DNS service? And you can go in and type quiz the senior dev.com in your terminal, and you'll also get this result that tells you who is our DNS provider.

And in this case, we use a company called GoDaddy. They're pretty big. But GoDaddy is just a distributor. In reality, they get their domain spaces from Verisign, and finally all that is regulated by IANA, which is an organization you've probably never heard of and nobody did. But it turns out that even if the internet is a worldwide network free from any kind of central organism, there is a certain called need to coordinate global things like DNS.

And that's what they do. They basically maintain the DNS. They write the specifications and then they coordinate all the companies that actually sell domain names to people like us that need a domain name. And Using timeless mental models, then check out the free training in the description. Moving on to the next concept, which is IP, the internet protocol. And really, this is going all the way down to the network layer.

Now, the internet protocol is basically a protocol for machines to find each other on a network. So they all have different addresses and you can send a package, and that package will find its way through all these network components to the computer where you intended to send it. Now, when I say package, it might sound like very fancy, but in reality, it's just a sequence of bytes. That can get interpreted into text, or numbers, or built into an image.

So it's really just a set of ones and zeros. And so basically, you can send a package from one computer to another or the other way around, this is what the IP protocol allows us to do. Now, the cool thing about the internet is that it's global. So you have all these mini networks connected to each other. You have hundreds and dozens and thousands of networks. And this is the whole value of the internet, that you can actually be connected with someone that's kilometers away without all the complexity of growing through all these networks and finding your way to their computer and vice versa.

Now, to support all this, we have a physical network and in this picture, you see the network of underwater cables that go from one country to another, and of course, we have also a lot of underground cables. And those are all fiber optic cables and so basically information travels at the speed of light, that's why the internet is so fast. At least with the cables, of course, there's a bit of inefficiencies when you have to re-out packages through network components.

Now, we mentioned IP addresses before when we talked about HTTP. Let's go a bit deeper. So, in our case, we saw that our IP address is 198.202.21.1. And then it's a port. You can think of the port as different doors that you can use to get into a specific server or into a machine, and 443 is a standard https port. Because nowadays we use https for pretty much everything. The other IP address is what we call an IP address V4.0.

And those IP addresses are actually written into the IP package. So, every IP package can explains a source IP addresses and a destination IP address. That's pretty much the IP address where it came from and where it's supposed to go. And that's how the network components know where to send that, because they interpret that and they're like, okay, you go here, you go there. Of course, this is a bit more complex because it's re-routing all the way along on the sub networks inside networks, but we are not network engineers.

As long as you know what an IP package is, you should be fine. Finally, IP addresses are the internet equivalent of real estate in real life. So they're very expensive nowadays. When the internet was set up, companies and even governments, they both a lot of IP addresses. And now, because we connected so many devices, there's not that many IP addresses left and our IP address starts with 198. Which stands for various registers.

So probably that was one of the latest IP addresses that were still available. Now, if you take a second look at this map, you'll see that some of the IP addresses starting with a specific digit are owned by specific companies. If we take a look at 17, that is the Apple IP space. And the funny thing is, if you go to the Apple website and you check for their IP address, you'll see that it starts with 17, at least in the US website.

And so that's pretty cool that you can actually realize that, you know, Apple is one of those companies that very early on claimed that IP space and boked it and now they have access to all those addresses and today, one of those spaces is extremely expensive. I mean, I'm talking about billions. And because we are running out of IP addresses and they're so expensive, around the 2000, people came up with the idea of IPv6, which are longer addresses that allow for more space.

Now, of course, this is still rolling out today, because again, everything you've seen was built around. There's so much legacy network components and we can just not, we cannot just make the switch. From one day to the other, but slowly we are moving towards IPv6, which is longer addresses that allow for more space so we can connect even more devices to the network. Now, congratulations on making this far, make sure you like and subscribe.

And in the comments below. I do get all the comments personally. Now moving on, let's talk about HTTP caching. And caching is basically using a file, like a JavaScript file or CSS file for a predefined time after first receiving them. And that will be the time to live. And we make this in order to avoid downloading it again over the network. Because downloading things from far away over the network, it's usually slower. So it's much easier if we know that the file didn't change to reuse it if you re-saved it somewhere in our drive. And so the browser cache, for example, which is a private cache, will sit just in between us and the server. And whenever the client goes to get a specific file, imagine we get a JavaScript file, well, that JavaScript file is being sent back through the TCP and IP network, and it gets stored in the browser cache. So the next time we need to get that file, we don't need to go to the server, we just reuse that version and we save up all that network time. And that time that we can actually reuse a file is called TTL. Now, in HTTP, they call that the max age. Now, whenever that max age expired, that means we need to check the server for a new version. And that's when we make a cache invalidation request. And we do that using E tags. And we'll see in a second what those are. But basically, it's how unique identifiers based on the content of the file, and so you basically check, hey, the file that I have has this E tag, is that still the latest version? And then the server says, hey, yes, this is still the latest version, and then you reset your counter, you reset your TTL. Or the server says, hey, no, it's not. In that case, the cache was invalidated. And you go ahead and download the new file, and you have the new version. So that's how the browser cache works. Now, how does this look in reality? Well, you can go over to our website or any website and choose any static asset. In our case, I went over to network, look at CSS and choose the first CSS file that Webflow injects in there. And if we look at the headers, the first thing you'll see at the very top, it's this status code. 200 okay from memory cache. So, if the asset is cached, you'll see at the very top that it's actually being pulled from memory cache.

enable the cache on your machine. So then you have disabled cache at the top checked. If you have disabled cache, you are disabling your cache. You see that option on the very top. In my image, it's checked, it should be unchecked if you're doing this yourself. So you'll get that 200 okay from memory cache. And then if you look at the headers, you'll see an age header. And that's basically how long the asset has been around.

How long has it been on your machine or in the CDN? And that should always be less than the max age. Now where is the max age? The max age will sit in the cache control. Now that number it's in milliseconds. So if you you could break it down in hours and and days. And as soon as the age gets bigger than that number, you'll have to request the file again. As we mentioned, you'll not get the file. You'll actually make a request to validate the file to see is this thing still valid.

And you do that with the ETEC, which you can also find in the response headers. And those are all the headers that the browser cache needs to work. So basically we have our age, we have our max age, and then we have the ETEC to revalidate our asset. Now if you want to learn even more concepts like HTTP caching, make sure you take our 10 minutes technical assessment. We built it with real interview questions, and it will tell you what your gaps are and what you need to fix in order to get the senior level or perform better in interviews.

Link in the description. Up next, TLS encryption. And before we understand TLS encryption and HTTPS, we need to understand why was it introduced. And the reason why TLS encryption was introduced is to prevent men-in-the-middle attacks. So a man-in-the-middle attack is basically someone sitting in between you and the server and intercepting all your data. So basically you make your request to the server, maybe you share an authorization header, or a password, or a credit card data, and you're supposed to get the payment back.

But what the attacker does is to sit somewhere in between. This can happen easily if you're doing this from a public Wi-Fi, they can install a Unix distribution called Kali Linux and the specific packages that they can use to interpret all the network traffic and then interpret those IP packages into HTTP and then basically get your HTTP headers or even the response. So it can sit in between and then intercept traffic.

Now, this was not the big problem if you're just getting a blog post, but as soon as we got e-commerce and we start paying on internet and doing things that are very important or we share confidential information, then that becomes valuable and that's when a lot of those attacks started to happen. And so in order to prevent this in 1996, which is basically 30 years ago, Netscape, one of the earliest proxy companies came up with HTTPS.

So basically with HTTPS, we will end to and encrypt our conversation and it's only our server that can decrypt those packages. We make a couple of different requests to set up the HTTPS handshake as we call it. And finally when the handshake is done, we will send over encrypted packages and it's only the server or the specific client that can decrypt those packages because they have a secret key that nobody else knows.

Now, on this part at the top is there to establish the HTTPS connection and it's done using asymmetric encryption. And we'll see in a second, what is the difference between asymmetric encryption and the second part which will be symmetric encryption. Now, the way this really works is that the server will have a couple of keys and one of them will be the HTTPS certificate, that's what we call the public key.

And so what the browser will do in asymmetric encryption, it's number one try to get the certificate. And then once it has the certificate, it'll try to verify it with the certified authority to actually make sure that the certificate belongs to the server. And to do that we did domain names, like okay, I got the certificate from this domain name, is this certificate really from the domain name? And that's why certificates are so expensive because you need to buy it from one of those certified authorities which registers legal information with your certificate.

Once they say that the certificate is okay, then the browser will generate a secret key. The browser then uses the certificate to encrypt the secret key and then sends it over to the server. The server will use their private key to decode that. And that's when we set up the connection. Why? Because this secret that the browser generates is now known by the server, the server will say, hey, the process was ok.

I know your secret, you have the secret. Let's move on to symmetric encryption and start sharing the real packages. As you see, it takes a couple of requests before you can actually start interchanging encrypted packages. And that's why HTTPS, it's slightly slower than HTTP. Now, why do we make this switch between asymmetric encryption and symmetric encryption? And the number one reason is because asymmetric encryption is very slow and computationally expensive.

But it's the only one we can do with someone anonymous. And the reason for that is because we have the secret key and the playable key, so we can actually give someone the public key, which is a certificate. They can use that to encode something and then they can send it back to us. Those two keys are mathematically linked in a specific way. Which makes it easy for third parties to encrypt things and then send it back to us and we can decode and then only us can actually decrypt that with our secret key.

However, this is very expensive and this is why we move over to symmetric encryption, which is very fast, but it needs one shared secret. So there has to be a sequence or a password that we use to encode these things that we both know. And of course, in the beginning, the browser doesn't know us, we don't know the browser. That's why we cannot jump in strict with symmetric encryption. And so what we do is to establish a connection with asymmetric encryption and then move over to symmetric encryption afterwards.

That's why every time you set up a web service, you'll see that people always ask, okay, download the certificate and then download the secret key and have them bolt on the server. And then the browser will download the certificate of a specific website when they make that first request to establish the HTTPS connection. And this is how the certificates look like, they are basically mathematical hashes.

And we can generate those in your machine or get them from a specific altoid. Now, let's move on to pulling, and this is one of the first concepts we'll touch on real-time communication. So we saw HTTP is basically sending letters, but sometimes we want a very fast update. And you don't want to go back and forth for that. You ask yourself, how do I get an update very fast? And the easiest mechanism will be through pulling.

And so basically pulling, it's actively sampling the status of something by a client. and so basically periodically calling an end point until a certain status changes. And so this is very much used when we talk about payment status, where the client or the browser will have an end point, which is the payment, and the ID of the payment, and maybe the status, and then it will go to the server, the server will say, well, you know, the payment is still pending. And then every five seconds or every three seconds, that's what we call the polling interval, the browser will keep calling the server and get a status until the payment is completed and then it will stop. And so this is the first way to have some real-time communication because we keep trying in the background and then from the user side they don't need to do much. And that's why polling is really cool and it's extremely simple, you can basically set it up with some basic JavaScript, where you have your polling function, that's just a fetch function, and then you use the set interval browser API to keep calling that every three seconds, and if you actually get the answer you wanted, then you can clear interval and stop the polling. And so basically from the user perspective, it will look like this, when it will keep refreshing and it turns out the payment is now processing, and now it will make another request and finally it will finalize. So this was the first way to give some sort of real-time update without an interaction for the user, so we make the user life easier. They don't need to like refresh the page to see the status, which was how they used to do it back in the day, they still tell you like, oh, just refresh the page in 10 seconds and you'll basically request the the thing again and you'll see if the payment was done. Finally, the status is completed, then we clean it up and we are done. Now, polling, it's a very limited behavior when we talk about lots of data or things like a chat system. And that's why we introduced web sockets. So remember how HTTP was basically sending letters and then receiving letters, web sockets would be the equivalent of having a phone call. Where you open a communication channel where you can both bi-directionally exchange things without formalizing every single message. You can actually, you have an open channel and messages can go from one to another very fast. And so, basically in web sockets, you will open that communication channel and the server will send data and the client will send data.

This is done with native browser APIs, so you can create a web socket and listen to a server and on the server you can create that with Node.js very quickly. So you could say, hey, let me listen to this web socket and you could send messages doing socket.send. And on the server side it's pretty much the same, you would connect and you would wait for a message, almost something happens, you'll send a message back.

So if you've never worked with those things, they might seem very complex, but in reality, the code itself is very easy and it's all done with browser APIs and node.js APIs under the hood. And this is basically what enable all these modern chat applications and social media where you have a back and forth exchange that's pretty quick. And so basically we have a server, we have two clients and user B will send a message, it would go through the channel to the server and straight to user A that will get notified without doing anything.

And the same when user A replies, it will go to the server and then to user B. Now, of course, if you do this at Facebook scale, it's going to be a bit more complex, but the main idea stays the same. Now, let's move on to another way of doing real-time updates, again with native browser APIs, which will be server sent events. And server sent events are used by all those modern LLM applications, so we keep getting tokens from the back end.

So as you see, they're very useful when you as a client made one request, which is that conversation request, and you keep getting tokens and tokens from the back end. You keep getting those real-time updates without you making a new query. And this fits straight in with how LLMs, large language models work, because they basically generate tokens one after the other. And so basically the way this works is that as a client, you basically make a request or you create a conversation, and then you subscribe to that, and then the server will be able to send events on that endpoint to you.

Now, if you go over to chat GPT, go to your network tools, and you look at the fetch, you'll find an endpoint that is conversation, and if you go to the event stream, you'll figure out that this is all the events they are sending to you. And that's exactly the messages that you've seen there. So even if these AI applications look very complex, you'll see that under the hood they are based on very low-level browser APIs that have been there forever.

Now. the newest protocols, we just T-I-P-C. And so, T-I-P-C is based on IPC, which is a remote procedure call. Basically, one computer causing the execution of function in another computer and then getting the result. And this was extremely old. This is even older than the internet, and this is the way they used to communicate in the early days where you'd run a function on different computer and maybe the result. But now they came back lately with TypeScript. So when we make a remote procedure call, we are actually telling the server, hey, go ahead and do that something and the server will do something. They'll execute that function that they have on their side and send us back the result. Again, the APIs to set this up are extremely easy, you'll basically create a IPC client on our browser and then try to make a mutation. That will go to the server and they declare if they actually have a match for that function. And all this is typed, so you get type safety between that CEO of you. So again, it's a very cool protocol, it's something that has been reborn, but it's only used in very specific applications. Rest APIs are still dominating and that's the one thing I would focus on if I would be learning. And the main reason why emote procedure calls are not so popular and the reason why they actually have been stopped being used, is because UI coupling the client code with the server. And so you're starting to have all these function calls into the server and back and forth and it's all very much spaghetti. It's all very coupled, and that also means that your server code will be very opinionated and it needs to know what's on the client, and then you get what we call spaghetti code. And so while there are very good use cases for it, it wasn't mastered out. One of the most popular use cases for IPC is MCP, which is the model context protocol, which is basically the open standard for connecting AI applications to external systems. So whenever you have these AI bots that you can tell them book a meeting in my calendar, they will do that with remote procedure calls. Basically, they'll realize, oh, the user's asking for this, okay, let me connect to the Google Calendar API and run this function. That's what the MCP servers offer to AI models. And so basically, you have these chat interfaces or IDEs and other AI applications

and you'll tell them, hey, do something and that will go over the standardized protocol, which is MCP, which is basically a set of texts so the model understands what the specific function will do, and then we'll call that function later for the answer, receive that, and then continue whatever your task is to do. That's how all those agent things actually work. In the case of MCP, it's not done over TRPC, which is TypeScript remote procedure calls, but the other JSON RPC, which is a bit more lightweight, and as you see, it was only published several months ago. So this stuff is pretty recent. Now, let's talk about the rest APIs and pay special attention because this one, it's very, very common, especially in senior front-end interviews. A restful design, it's an API architecture style where we treat entities as separate resources with an uniform and standardized interface. So, basically, it's a way to add some order in this HTTP chaos. Because remember, even if we had HTTP, which was a protocol for the network communication, when it comes to the request itself, you could basically freestyle. But the problem when we freestyle and we all build different APIs is that every time somebody needs to consume an API, you're reinventing the wheel. So if we look at an e-commerce example, let's imagine we have a product, which usually has a price, a name, a description, maybe the product ratings, and a delivery time. Now, both the price, rating, and delivery time can be other complex types. So, they would probably not be just a number, because maybe product has also currency, or the rating would have a note, or and a description, and then the actual rating. So, you also have this compound objects, and once you model your domain into all these different objects that you have, you might store them in the database, but then you need a way to consume them over the network, and that's what the rest gives us. And so, basically in the rest API, it's all about the URI, which is basically the unique resource identifier. And this URI will be the name of that resource in plural, so we might have slash users, accounts, products, repositories, that will be the base.

is for example if we want to list all the products, we will make a get request to the endpoint/products. And that will give us back the list of products. Remember, get is that HTTP method, the HTTP verb, and products is actually the URI. Now, there might be cases where not only you want to get the products, but you also want to filter them or paginate them. So, a real production URL for a rest endpoint would look a bit more complex. We might have our URI, but then we'll also add what we call query parameters. That's when you say, well, I want the first page, I want 10 elements per page, and maybe even add a search query where you look for a specific product or a specific name or category and so on. And that's pretty much all part of rest specifications. And the good thing is that all the APIs that implement a restful design, they will look very similar in that way. So if we were to model a e-commerce example, we will have a/ products endpoint, we're looking at all the products, but on the product we might have prices. So appending to that endpoint, we could add a/ product ID/ prices, so people will get one product ID and then for that product they can get all the prices and then get even a specific price because maybe a product has multiple prices. Uh the same goes with rating. You could actually get the ratings from a specific product or have a specific uh rating endpoint where you can get them by rating ID and the same goes with product reviews. So basically what rest gives us is an ability to model all those endpoints in a way that looks predictable. So when you are in the front end, it's very easy when you know that you need to consume the products, you know exactly what operations you can do and what the URI will look like even without checking the documentation if they really implemented a restful API. So to put it simply, rest it's basically standardized code over HTTP. And crud stands from create, read, update, delete. So basically rest it's a way to standardize those operations over HTTP. And so when it comes to crud, we usually have an operation called create with the first one, then we have read, update and delete.

It will mean that we make a post request to create a product to the product URI. After we created the product, we might make a read to get that product back. So we make get with that product ID to the same URI. If we want to update, again, we do a put or a patch. Put will basically replace the new object or create if it doesn't exist. Patch will just apply a change. So these two are slightly different.

Uh for the most part, put it's a better one to use because it's idempotent. Whereas patch is not idempotent, I will not go deeper in idempotency in this video. But but it is explained in other videos from this channel. And finally, there's the delete. And so as you see, if I have the URI, I can immediately know everything that rest API offers me without even reading the documentation. Again, if it's well implemented.

So that was the purpose of implementing a rest. But rest is not enough anymore because not only we have desktop applications, but we also have mobile applications. And if you try to model these two with rest APIs, you get into all sorts of problem. And the bigger problem is that on the desktop, we usually have lots of data, many different endpoints providing this data, so many separate endpoints. And the list and detail views are mixed.

So you might click on a product and then you want to see the full product. Detail view, it's much more detail because we have more screen real estate, so there's more space. To show more data, so the problem. On the desktop is that there's just too many requests, we cannot get all our data from a single request. So you end up making just to load a single view, you end up making dozens of requests to many different APIs.

And that's what we call under fetching because a single endpoint. cannot give you all the data you need. When it comes to mobile, it's a bit different. In mobile, we have less screen real estate, so less screen surface. That means we usually provide a more compact view of the same object. And we also have poor data connection and less data budget. Because people usually get a contract. and that used it a lot.

And so the problem generated is that we usually fetch too much data. If we use the desktop endpoints, uh we have bigger objects and we get all that data, but we only display a subset of that, we already fetch all that JSON data and we're consuming data without showing it. And that's what we call overfetching, cuz we overfetch data. And we use the same endpoints as we use for desktop, and then we're getting too much data on board.

And to solve this problem back in 2013, a team of Facebook basically invented GraphQL, and then they open source it and make it available for everybody. And so what graphical is, is that it's a data layer where you can query multiple resources in a single query, and you can avoid underfetching and overfetching. Because you really as front end control the exact data you get from the GraphQL query layer.

So you have this interface where you say, give me this object with this many fields and then this other nested object and I only want these three fields. So you really get exactly what you need. So on the desktop, for example, rather than making all these different requests to all those suggest APIs and having the problem of underfetching and making more subsequent and sequence requests to get all of them, what you do, it's a single query. And in that query you write everything you need from the data layer and then you get it back.

Another benefit is that GraphQL it's typed. So you really know the types of what you're getting and you can use that in the front end to write type safety code, whereas for rest to be safely typed, you need to add extra tooling to it. So GraphQL also has amazing developer tooling out of the box. And so that's how we can translate thousands of rest requests into a single GraphQL query and have less round trips.

And the same goes for mobile. If we want a different view, the only thing we need to do is to change our query and then we get less data. So that's how we solve underfetching problem, because we really can write a query that contains only the fields we need. So GraphQL basically solves these two limitations of rest, and it's extremely useful when you have different clients, where you have a mobile client and you have a desktop client and they all request different data.

It gives free freedom to the front end, to really build what they need without you having to change your data layer. Normally in a rest, when they needed a new property, you need to change your endpoints and then you'll break the restful design and start improvising. That's why if you look at any REST API today, you'll you'll realize that it doesn't really follow restful design because in practice you need to take all these shortcuts. With GraphQL, all that is solved because it gives the front end the freedom to really query what they need. But GraphQL also introduces the n + 1 problem. And this is a mathematical problem that happens because whenever we get, let's say, a product list, um and so in this case we are getting 24 products, what will happen is that we select all those products, but then we also need to make an extra SQL query, right, a database query to get each individual product. And then we put all that together in a single JSON object and send it to the frontend. What what happens is our graphical server, it's bombarding our database, and it will basically make, in this case, 24 + 1 requests. So that's 25 SQL queries for a single graphical query. Imagine you have a couple of clients and all that translates to all these SQL queries, you'll end up overloading our database. So, one of the first problems you need to solve when you build a graphical server, it's solving this m plus one problem. Because if not, you'll find yourself in hell and the performance you actually get, if you don't solve this problem, it's actually worse than you had it than the one with rest APIs. And so the way this is solved is that instead of really sending all those queries from our graphical backend to our database, we use a library like data loader. And what data loader does is to batch, so it basically takes all those different IDs, puts them together and then builds a single query that gets sent to the API. So rather than sending those 25 queries, when we make that graphical query, we actually send one bigger compound query. I will not get into the implementation details, but what's important for you to know here is that whenever you need to aggregate those different queries, there will be some magic you need to do to avoid overloading your backend services. And you can do that with data loaders, where you can build your graphical resolver.

your backend code in a way that is actually scalable and you'll need the data loaders for that. And that's what they solve. They basically batch queries and send them in a single query rather than sending them one after the other and having the M plus one problem. Now let's move over to more architectural topics and the first one is basically the API gateway. So an API gateway it's a reverse proxy that unifies repetitive functions like authentication or SSL.

So instead of having to implement authentication in all the different microservices that we have, we implement it once. What's a reverse proxy anyways? Well, whenever we have a client on the server communicating with each other, you might add a proxy on the client side like a VPN. So me as a client, I could have a VPN that pretends to be someone else and that would be a proxy because it's acting on behalf of the client.

The server thinks is getting the request from the proxy, but I'm actually making the request behind it. Well, a reverse proxy would be different. In a reverse proxy, it's basically acting on behalf of the server. And that would be a load balancer or an API gateway, they sit right in front of the server and they act as a reverse proxy. So now that you know what the reverse proxy is, so what we saw is that in order to satisfy the data needs for this complex UI, you might have different microservices and you end up making a request to prices, products, shipping data, all those things are different back end teams that implement their own microservice.

And they all need to somehow implement authentication, HTTPS, so you as a client can actually use their service. So there's all this repetition and repeated work they do. Because they reinvent the wheel pretty much every time, so if you think of our products, microservice, they'll have to implement, for example, their own rate limiter, they'll have to add a middleware for authentication, they have to add caching and so on and so forth. And all those things are kind of similar in all the microservices.

They really don't change. And we call them edge functions. And so in order to solve this problem, we introduce a reverse proxy, that is our API gateway, which will basically sit in the middle. And so it will receive all these requests. functions like the rate limiting and out and caching only once and process requests. Once the SSL handshake was done, once the caching policy was satisfied, then it will forward the request to its corresponding microservice.

And that's how we remove a little bit of work from the backend team. Now, API gateways are things you can buy with a single click. In this case, you see the diagram of the Amazon API gateway, and one of the advantages is that we only need to buy an http certificate for a single service. That's our API gateway because behind this API gateway, we can actually run over http. And if we remember our talk about TLS, because we then need to set up the TLS handshake, which takes at least five round trips to the network, we will be much faster if we have http connections inside a virtual private cloud that's not open to the internet, so there's no opportunity for a man in the middle attack and we do the http handshake

only at the API gateway level. Now, you can actually build your own API gateway using engines, and if you want to do it on localhost, you can do that with Docker. So basically, you dockerize an instance of engines and that's your server, and then you forward the traffic to a backend for front-end component or any other service behind it, and you could run all these clusters on any machine with Docker containers.

So this is just to illustrate that yes, even if you buy those things with one click from cloud provider, you can also build it yourself if you really need it to. Now, in the last couple of videos, we've been basically focusing a lot on the front end, but if you want more back end related content and full stack related content, please let us know in the comments just like, subscribe to the video and comment full stack on the video.

And we will take that into count when we plan our next video. Now, concept number 14, let's talk about the backend for front end. Basically, where we are right now is that we have this complex front end application, it makes all these different request to different microservices, and it does all that through an API gateway. But this is not enough for modern systems. What happens in reality is that all these different services are owned by different teams.

So you got the front end team that owns the front end. Then you might have a platform team. They usually own the DevOps and all the cloud infrastructure, and they are usually the ones maintaining the API gateway. Now, those requests get forwarded to the different microservices, and usually the different microservices are I own by different backend teams. So, for front end to actually release a feature, they need to sometimes talk to the platform team, they they need to coordinate with the products team, then the shipping team, and remember all those different teams have different backlogs, have different product managers.

So, at an organization level, it gets very confusing for the front end and it takes forever to release features. Now, I remember I once worked for a company where we had 300 microservices. That's enough to go crazy when you have to implement any single feature. And so, to solve this, we introduce the BFF. That's a backend for front end. And this is another reverse proxy, but it's built for a specific front end client and owned by the client.

So, basically, the backend for front end will be owned by the front end team. And the goal of the backend for front end is to build a data layer, most of the times using GraphQL that is specifically directed to that front end and it's own by the front end. This is why, as a front end engineer, you are required to know the full stack, because it's front end engineers that will be extending the backend for front end.

And this allows companies to move very fast because you don't need to go ahead and make changes or talk necessarily to the product team or the shipping team. You can just make changes to your web BFF, get the data from the microservices, but then present it in whichever way you want, and then send it back to the front end. And this gives the front end a lot of agility, but it comes with the fact that, as a front end engineer, you need to at least know how to write some backend code, some resolvers, or at least extend some GraphQL schema types.

So, if you want to become more valuable as a front end, the one thing you can do is learn a bit of full stack. Now, because this backend for front end is built specifically for the desktop team, that also means that if you have a mobile team, they will be able to build their own backend and front end for mobile. And they will it's really tailored toward whatever the mobile specifications are. And so this allows them to move very fast.

And so all of a sudden our architecture is scalable at least in terms of people. We can have many different teams working independently and delivering features safely without the necessity of communicating to each other all the time. But as you see in the picture, our API gateway starts taking a lot of traffic. And there'll be a lot of pressure on that specific component, and it's also a unique point of failure.

So we need to be very careful because if the API gateway goes down, the whole thing goes down. And this is when we go into things like load balancing. So basically load balancing would allow us to distribute traffic between identical instances based on a specific algorithm. So we can have many different instances of the API gateway receiving traffic. And so if one of them goes down, the whole system is not down.

And we can dig up also a lot more traffic than any single instance could take. So as our API gateway starts receiving more and more traffic and things start to heat up, we can actually replace it with a group of smaller instances, independent instances and a load balancer, the ELB. And this load balancer will distribute traffic between those instances based on an algorithm. I will not go deeper into load balancing algorithms in this video.

But just wait to know the most common is round robin, basically you go in order and you distribute traffic from one instance to another. Now, even if this is the most common algorithm, it's not the only one, and we also have other algorithms like list connections, which basically will send traffic to the instance with the least connections open. So that's a way to adapt the traffic distribution to the performance of the instance.

Congratulations, thank you so much for your attention and if you want to go even deeper in the front and make sure make sure you check out our video on every front end architecture pattern explaining 23 minutes. Or the 15 front end concepts every senior front end has to master where we go deeper into specifically the front end part.