How Frontend Engineers can master the Full-stack

If you're a front-end engineer, you probably noticed that there is no longer enough to just know some React, Angular and be able to build UI components. Companies these days expect you to contribute on the back end as well to be able to deliver end to end. In this video, we are going to cover 10 full stack concepts that every front-end engineer needs to know to successfully make the transition towards a more full-stack oriented developer.

Okay, so we usually all start here with the front end where you probably build components or even full features, you have your state management and you usually get data from the back end. And then users, you know, do certain actions and you send an update, you either create something or update something and that goes to what we call the data layer. If were to apply the principles of layered architecture, this would be kind of our first domain.

And the most traditional way to do this and the most common, even nowadays, is to use a rest API, which you probably worked with before. Now, if you are a front end developer, you usually make requests and receive data from a rest API, but as you want to move towards a full stack, you want to get a bit deeper. And the first step there would be to really understand HTTP, which is the protocol behind rest, right? It's all about requests and responses.

And the easiest way to think about this is to think about it as an email, as a piece of paper where you have text, so you're sending text over to the server, the server will break this down and it will try to extract the method, the path you want to go to, the protocol you're using, and then certain headers, which is like data about the data. It basically tells you what's inside that request, and the server will fabricate a response.

So basically it will send something very similar back, but you'll have a status code, not included here. And that body can be usually JSON, if you got data back or HTML, if you got, you know, the your HTML file. Now, in the rest context, most of those requests are made to a uniform standard. That's why we call it rest. So, the way you design your endpoints, it's basically specified where you have resources. In this case, it's a resource called survey. And then you have ID for that resource. And then you can make requests to make all the curd operations, so create, read, update, delete. And to do that, you'll always use very well-defined HTTP verbs. Now, probably, as a front-end engineer, I'm asking myself, how much do I need to know about rest APIs? Do I need to memorize all the HTTP codes? Do I need to be able to build one myself? So, a lot of people would go in and try to memorize the definition or some endpoints. The best way to learn, it's always if you if you can get some hands-on experience. So, going back, if you are employed right now, I would go back to your codebase and look at all the data requests that your application is making. And then try to get the backend on board, if they implement best practices, they will have what we call the open API standards, which are a way to document the API. And they should have this view, which is the swagger view, it's a tool that will generate this UI. And this is where you'll actually see all those restful endpoints. And so, I would start here, I would start from the outside, understand the API very well, and then, if you can, try to get more and more closer to this data data layer and see if you can actually extend one of the endpoints. It might be the case that the backend developer gets sick, they need someone to get something done and release it fast, and you can get hands-on on this. This is a lot easier if your backend it's in TypeScript and Node.js. It's a bit harder if it's in C# or Java because it's like a new language.

that's the first two things I would do. In the interview, what they mostly ask in a full stack interview, it's can you write down really quickly the endpoints for this resource? So, I would definitely know how to type out at least one resource, you know, being users. I'm like, okay, if I want to get the user, what is the request I make? If I want to modify a user, if I want to edit it, and if I want to delete it. And what are the typical responses? Okay, like you should know a 404, what does it do? Like or a 503 at least, or a 401. You should have that language of the data layer. And this is probably the biggest quick win that front-end engineers can can do right. Because at that point, you are able to go query data yourself, maybe even debug debug the the API yourself. So you gain a lot of independence. I remember uh one in one of my last positions actually, uh we were implementing a public API and uh the the back end developers in the team, they send me the the Swagger file over and I didn't know what it is. Unfortunately, I was the React dev and that really made me come across as a junior. Like they said, hey, you just have the Swagger file. Just use that, you know, to configure your your React app and I was like, I don't even know what it is. And we were using open API standards, but that was never I never heard about them. It's probably something that's very common for each other, for other software engineers, but yeah, I came across as a as a very junior dev. And I had to learn these things from scratch. Okay, Bogdan, and regarding rest APIs, what if I want to go a bit deeper? So, a very common question you will get would be also around scalability with rest. They'll probably ask you, why are rest APIs more scalable and idempotency, it's also a concept that they might ask you about. Even if you're on the front end, they expect you to know those things. So, you want to understand idempotency, I added a mathematical example. Basically, an impotent operation, it's one that if you do multiple times, it won't change the final result. The easiest example, it's multiplying a number by one. It doesn't matter how many times you multiply a number by one, you'll always get the same result. So your API endpoints

except for the post endpoint should aim to be idem potent. And the reason for that is because probably in the front end, whenever you have a request that fails, you might have a retry mechanism. Well, the problem is, if by any chance you retry a request that didn't really failed, you might not doing the same operation twice and having all kind of unpredictable changes to the database or to your API. So, that's why we aim for idempote, make sure you look this one up. If you want to go even deeper, do make sure that you look at DNS and also at the different network layers. We usually work at the very top layers. There's around like seven different layers starting all the way with the hardware, you most likely will not have to touch anything that's not at layer six and seven. This is where we usually work, where you have at layer seven DNS HTTP. But this is all built on lower levels of abstraction, and it's not about knowing everything, it's just about being aware. That as an application developer, that's the layer we are working with. If you mention those, you'll already really stand out, very few people can name those. And finally, do make sure your list gives some read to the IP and TCP protocol, understand, okay, that's like, you know, IP packages, IP standing for the internet protocol, they have a header that tells, you know, where is this internet package coming from? Where should it go? So that's what all the network components use to route that package to the destination, and inside that, you have the IP data. But if we're talking about TCP, which is what HTTP is based on, you'll also have more information to make sure that those packages arrive in order. And that's the beauty about TCP, is that they would come in order, so as a developer, you wouldn't have to worry about kind of whole, you know, this response that's chunked in all the small packages, was there an error? Do I need to build them together? Basically TCP guarantees they arrive in order and that there's no there's no package loss. I'm not going to go deeper into this because it you could really make like a three hours video on it, but do make sure you

you read about it just so you have more context. You just didn't go like, oh, HTTP and that's it. I remember one very common interview question was, hey, what happens when I type google.com in my browser? And I remember senior engineer, senior front engineers who were not able to to answer this. Back in my junior days, I bought a very thick book on networking, and I was like, I need to learn this stuff because if not, I'm not a real engineer, I only know React, and the best way is to go deeper.

But then I dropped it, you know, I've read like 15 pages, it was very boring, and I realized, it's good to know about it, but it didn't made such a big impact, and I had other topics to worry about. So my question is, how deep should I go? Should I just check some documentation, you know, MDN and see how these things work at a high level? Exactly. So unless it's something you're working on with every day, you will forget it even if you studied.

And so a lot of people go in, they yeah, they buy a book, they try to read it. Books are very dry and a very poor way of memorizing things. So, unless you use it, you'll lose it. That's the old saying. What I would recommend is you need, it's a bit like starting history. You will understand it, but you're never been through those events. So, whenever it's something that's outside the immediate scope, think of it as starting history where you need to understand the events.

It's not like you've lived through them, but you do need to know IP, TCP. I mentioned them to at least the level I just did, and have this coherent story of how they add up to what you usually work with. And just a quick note on caching, HTTP caching is something that a lot of us take for granted, just because it's implemented by the browser, but very few developers can go into the browser console tab, look at the headers and tell you, what is the state of the HTTP cache?

This is extremely useful when you're about scalability in the front end. And when you talk about static assets, basically the browser will look at the response, and there's headers like the cache control header will have a value. And based on that, we will think, okay, should we, you know, reuse this response or make the request again and again? says, you know, we shouldn't use this where it says, you know, it's in a private or public cache. Then, there's usually a max age attached to that resource. To that CSS file or whatever the response is. And basically the max age says, you know, keep this for 60 seconds and if it's been longer than that, check with me if I have a newer version. And the way we check that is with the ETag header. All those headers, cache control, the max age, and the ETag, they are on all your static resources. So what I would recommend, you know, tomorrow when you go back to work, open your application, look at any static assets you're requesting and try to find those and make, you know, understand how your caching works. You can find all those in the network tab, so go to your browser, pick any request that ideally should be a static assets, like a JavaScript file or a CSS. Go over to response headers and you will find the cache control, as you see in my case I have a max age of 86 400,000 milliseconds. And you will also find the age, so we have the max age, right, and then we have the current age. And you can also check the ETag for the cache invalidation. So, make sure you look at those and understand at least a little bit about HTTP caching, which most rest APIs will implement to some level. Super important also for the front and right when you are being asked, hey, why is the application slow, one of the things you will have to look into and we will talk about that later, but caching, it's one of the things you might look into it. I think in the first 5 years of writing code as a front end dev, I you take into that tab, that console tab and I would be totally lost. A good idea would have been to actually learn these things a bit before. It would have saved me a lot of lot of time. And I remember my CTO Java developer 20 years experience and he would from time to time. still go into the network tab and look at the request and knew how to interpret them. Right, which was awesome to see. Yeah.

The next thing would be looking into graphQL. And that's pretty much a newer technology on how to do data fetching. And the reason for graphQL was because the rest has a lot of limitations. One of them it's the underfetching. So basically underfetching is whenever you had to fetch a list of items, let's say with certain properties, the general resource endpoint might not give you enough data. So then for every record you get, let's say you have a list of users, you'll have to make an extra request to get all the extra information. To fetch a single view, you might end up having to make dozens of requests. And so graphQL comes in and says, you know what, as the front end developer, I'll give you a data layer, very similar to a database where you can just make your own queries and get the information you need. So all of a sudden all those different requests become a single query and a single response. Uh when is this useful, Bogdan? So basically graphQL will allow you to scale when you have a single data layer, but you might have different clients, so you might have a mobile app, you might have a desktop application, and they all want different views, they all have different data views, and the natural tendency there is to start making a sort of a Frankenstein from your rest API, but the easier cleaner way is to move on from rest to your graphQL layer that all those different clients can request as they want. And that's what becomes the BFF, which is another core concept if you're a front-end developer moving to the full stack, this is usually the first part of the architecture you can contribute to, which is the back-end for front-end. Uh what does the back-end for front-end really mean? Um, so basically the back-end for front-end would be a back-end application that's built by the front-end for front-end clients. And behind this back-end for front-end, so basically that would be our component, you have this graphQL query that's

simplify something for the front end, but behind it you have all these services that are basically being requested by the graph call server, and then the response is kind of stitched together into a unique single response that then goes to the client. So, this is usually built by front end plus full stack developers. Back end developers would usually build those services. So, for example, you would have a back end for the mobile app that would unify all the services that the mobile app is actually requesting into one layer that the front engineers can easily query. Right? And then you would have a a back end for your web app and it's totally it can be totally different or at least significantly different than the the back end that you built for the uh for the mobile app, right? That's that's the idea that you unify the needs of a front end client into a data layer that's tailored to that client. Yes, the beauty about graph curl is that you don't necessarily need to split into different back end for front ends that early. Unless you have very different requirements, graph curl gives the front end the flexibility to choose what they can query. So, for the most part, you could do with one back end for front end. If you build a back end for front end with rest, then yes, you would need a back end for front end for each specific client, because the requirements would be so different on your endpoints. There will be no way to just have all that in a single Frankenstein rest API. Yeah, folks. And the the the issue here is that unless your company is using GraphQL, you won't really be exposed. So, I guess our advice here bug is to understand what are the advantages that GraphQL brings and why GraphQL was invented in the first place, right? To to bring more flexibility to the way we fetch data, ideally. And that's why it's called a graph, because you can navigate it like a graph. And do remember that graph curl is based on graphs, where in a rest we had resources and they're kind of independent. Graphs are nodes that lead to each other. So, you'd get, you know, Monalisa, but then you could go straight into getting all the information about

Vinci and whatever else is related to Da Vinci. So, you have, again, a lot more flexibility and it gives you as a front end developer optionality. It means you can basically choose how much you want of the graph in a single query. So, basically whenever you query, you are basically saying, you know, give me Mona Lisa with the museum where it's in and um whoever painted it or whoever discovered it. So, basically, you have the opportunity as a front end to choose, right? And then I could have another subset. Whereas with rest, you just get that resource. Like you make a request and you get everything back. And so maybe in that response there's a lot of things you don't need, that's over fetching, or there's still a lot of things missing. That would be under fetching. And finally, I see, you have uh the n plus one problem. This is specifically for interviews, right? Where you're being interviewed at um Bograf Girl. Can you tell us more about that? Yes, so as you've seen here, we have our query, basically, you kind of make this request to get different records and what usually happens with n plus one is that, let's imagine you are requesting a product, a list of products. And so, depending on how your graph layer it's implemented, then you're saying, okay, I also want for each product the price of each product. So, you end up making an extra query to the DB for each single product and so that's why they call it n plus one, because basically, in terms of trips to the database, you're making this trip to get like the list of products. So that's your one and then depending on how many you returned, maybe it was 100 products, you make another extra 100 queries. So that's why this is n plus one and what can happen is that you're basically doing a DOS on your own database. Because you have to resolve all the different fields for all those products and you do that all those queries at once and your database you might like kill your own database, right? Yes, all those queries are independent queries that go in the same moment, imagine you have 50,000 users, you multiply that by the query they're making and you will overkill you

your database server. So the solution to this is to just unify your SQL queries before you send them over in a single one and so basically all this becomes a single query. There's a specific library for GraphQL that helps you do that, it's called data loaders. But again, this is probably one of the most common interview question when it comes to GraphQL, especially if you worked with it as a front-end developer, maybe you never had to handle this because it's the backend developers that do it.

Do make sure you try to figure out how you are handling it right now in your code base at your workplace. That's usually one of the best way to start. Okay, so we're still at the data layer, we've seen GraphQL, we've seen REST APIs. That would be around 95% of the work in a on a everyday basis, but there are scenarios where we'll need more than just requesting and responding data. And that's the third and last concept on the data layer, which is basically data streaming.

So data streaming is very useful when you have any kind of live updates, so you want to see a graph that updates as things happen in the back end. Or you have like a chat application and you want to receive messages live from another user. You could do that with traditional HTTP, but it will require a lot of work, you could just call your backend every 5 seconds, but that puts a lot of pressure on it also.

So, we kind of develop this better technology, one of them it's web sockets. And in web sockets you're opening a channel with the server where the server can send messages to you as the client, and you can send messages to the server. And so, normally in a chat application, you'll have several clients connected to the same server and basically sending and receiving messages. That's how WhatsApp, Facebook, Instagram, that's how they all work.

They're basically opening applications like GPT where you will get you'll make a query to the chat and then it'll kind of stream data back to you. But what are we they realize is that you don't really need a web socket in this case because you're only receiving a lot of messages, but you're only sending one question. So if you go to the network tab, you'll see that open AI is basically sending you all those chunks of the response.

Even if you send them one sentence back. So whenever you have this kind of asymmetry where you send as a client one message, but you got many back, that's when you can move over to server sent events. And server sent events are a much simpler API than web sockets, they are a lot more scalable, and they're very easy to implement because they are native in the browser. So you literally need two lines of code to start receiving events.

Keep in mind that whenever the communication it's asymmetric in terms of the client it's sending a lot less messages than the web server, you can switch, you don't need to go full mode web sockets, just to serve a cent events and you'll be just fine and it'll be a lot easier and more scalable to implement. And I guess this is very much worth looking into, especially if you're interviewing for a company that's looking to integrate open AI API or any kind of LLLM into their products, right?

So definitely check out server sent events because it's probably something they are dealing with. Now, we finished looking at the data layer, we saw the request and response model with rest APIs and graphQL, and then data streaming with web sockets and server sent events. And as you move deeper, you will go to the business logic layer. This is where all the business rules are implemented, and this is where you can think of this as the actual brain of the application.

That's where the decisions are being made. And whenever the backend devs talk about business logic, that's where basically it lives on on the server, so when requests come in, they're being processed or validated and then there's certain rules are being implemented, just like if statements and certain business procedures and based on that there are calls being made to the database which we will touch on later. Okay, now the second part of the back-end it's the business logic layer and that's what back-end developers refer to as all the logic that happens after a request comes in. So you'd have that request, it gets intercepted by our rest API, and there's usually functions attached to it that will trigger and then probably interact finally with the database. That's what they call the persistence layer. So we are going to focus now on this layer in between and this is where all the logic, all the business logic that's being implemented, it's actually being processed. So this is basically kind of the brain part of the actual back-end, where the database will be more like the memory where you remember stuff. This is where you actually process things and make decisions and decide what to do next. Now, in general, there's a lot of coding and they usually group those in controllers, that's what we call it, is basically classes that do certain logic. But you can think of it as, again, the brain behind the back-end. Now, what it's a very complex topic by itself. We can make a different video about it, but do make sure you look into it. It's very mentioned in full stack interviews. The most common question would be, okay, you get you are getting this JWT token, JSON Web token in the front-end, but what's the life cycle of that token? How did you obtain it? And what is the back-end doing with it? You want to make sure you can answer all those questions. Again, I'm not going to dig deeper into this because it's a topic by itself, but we can touch upon it in next videos. Once the user is authenticated, the next thing would be to sanitize and what we call validate the data, that means making sure that whenever they send you an email to our API. Then it's actually an email, uh making sure there's no JavaScript injected in our username, let's say, and all those kind of dirty, nasty things that attackers can do. And once that's done, we move over to

actually persisting data, saving data, and usually most backend frameworks would use a type of object called a DTO. That's a data transfer object. So the way you can think about this is, let's imagine you want to create a user, you send the username, the name, and the email. But then we need to somehow clean this up and make sure that's something that it's supposed to be persisted in database and that's where we use DTOs. Again, this is very abstract and unless you get your hands on to a back end code base, it will be harder to grasp. But you can think of it as the packaging of data until it gets to the database. So before we send it, we're going to wrap that up so it has kind of a uniform, it has a uniform shape. And then we will move that around different back end pipelines until it gets persisted to the database. Mhm. So for example, if I understood correctly, you can have a DTO in a Node.js server and you would just receive a certain object from the front end for a form, let's say a user submits a form, it goes through the rest API. It gets to the to the back end and then you process that with your DTO and then probably the next step would be to persist it. So you're kind of processing, uh processing the data. Using the data transfer object to to process your data, right? Yes, you basically package your the data that came through into a clean DTO that's ready to be processed by the persistence layer by the database. Mhm. And so, talking about databases, that would be the final layer. And this depends a lot on the project, but most of you probably heard about the SQL database or Postgress database. A lot of people are also talking about Mongo, although it's not like no SQL databases are not so common, but this is where we actually store things. This is where things that we're supposed to remember or the application is supposed to remember will be persisted. And they usually live on a hard disk, just like everything on the computer. Even if this is abstracted by the cloud and people talk about the database, in the end it's a computer with a hard disk.

So, for the most part, the easiest way to think about a database is as it would be a file that you can actually query. Like you have this fancy language where you can retrieve things very easily, whereas if you had a text file and you need to find something you added there, you'd have to kind of go line by line and figure out where that record is. What databases do is they add this layer of abstraction where we can actually write intelligent queries and make just much faster when we get data back.

But you can mostly think about it as it would be a file. And when it comes to the databases is basically two big categories, and this is based on the data you're storing. So if your data is unstructured and you want to keep it like that, those should be no SQL databases where you just have this kind of open form JSON, or well there's different there's different ways. But let's think about Mongo, you'll have this open form JSON and it doesn't really matter what you add there, it will go in and then you'll be able to somehow retrieve it later with the ID.

But there's no guarantee over the shape of the data you're getting back. So again, no go strains, but also no guarantees. By unstructured data, we mean any data that doesn't have the same shapes. As you see, all those files might have different totally different order, they don't need to look the same. There is no predictable structure, one doesn't look like the other. The usual problem when we use this in a business setting is that your schema your data might change.

So let's say product the product owner comes in and says, well, now our user needs to also do this. And then you add to that, but all the users you had that didn't have that property. Like let's say now, every user needs to have a favorite color. Well, everybody that was created up to this point will not have one. And that's the problem that you'll make a query for all your users and some of them might have a favorite color, some of them might not.

And there's no way for you to write solid logic that scales without you having some predictability. So the advantages, yes, it's very quick, you don't need to worry about the shape of your database, and it's really like ke, instead of having an ordered closet, you just have a room where you throw everything in. But at the same time, they're very fast and very scalable. For most business applications, you'll probably have some form of organized storage and that would be our sequel database.

And this is one of the best representations I could find where you see every single piece, depending on their shape, it's toward in a specific way. You cannot just go in here and add a red one, there'll be an error. So you can think of this as a relational database, an organized storage that has strong rules about how things should be stored. 100%. Not only that, but the shape of the things you put in has to comply with the shape defined.

So you cannot just throw in random pieces, they really have to comply to a shape you've defined. And that's what we call a database schema. So schema is the declaration of all the columns, all the fields, all the data types that make up your database. And as we see here, there's a user field, if someone comes in and tries to add a field on a user that is not here, you'll get an error. And so the beauty about this is that you get a clean version of your data that looks exactly like it has to look, the fields that are supposed to be there are always there.

And this is how 99% of business software is being created because you need this kind of organized structure to really have what we mentioned before, the business logic and some predictable output. Now, most architectures would use a mix of those. So remember, they're both useful, just depends on the use case you have. A very good use case for unstructured data, it's whenever you don't have a lot of relationships or business logic with that data.

A good example, it's when you're storing logs, you just want to store that a user logged in at this timestamp, and that's it. So, you'll have a lot of frequency, you'll have a lot of those. those records, but there's no relationships between them. In contrast to organized storage, which is a very good use case would be e-commerce, where you have products and prices and catalogs. And all those relationships have to be really well defined because they are really meaningful.

And that's when you need to switch towards a relational database. Now, finally, even if you're a front-end and you touch a bit of the full stack, in most system design interviews, they will ask you about database scalability. You don't need to be an expert, but you need to be able to at least reason about it. And the main mental model that governs database scalability is the cap theorem, which basically states that you cannot have those three quantities at the same time.

So you cannot have consistency, availability, and partitioning at the same time, you can only have two of them. Now, this is very abstract, so it's a lot easier if we apply it. So, let's think about scalability, basically scalability would be how does your database behave? When it gets a lot of requests or a lot of data. Now, when we have one of those relational databases, for the most part, all data lives on a single server.

Because we're making queries and queries might be composed, right, so marked one this table with this table and this other table and this other table and this other record. And so, it's all in a single server. So when our traffic scales, we end up having a problem which is we either add more hardware, which is usually very expensive. You know, you increase this hard disk. Remember, we had this hard disk, we just increase the CPU, the memory so it performs better.

But then it will get to a point where even this is too small. You get kind of at the physical limit of what computers can do. And that's when we need to rethink a bit how we manage our database. Now, the first way to scale your database is by implementing the read-only pattern. And so basically what do we do here is that we still have a single DB, that's our master, where we read and write, but we offer replicas where different database clients can read from. So basically, our backend can write here, but we might have other services reading from here. So there's not so much pressure into onto this single instance. Now, if we were to apply the cap theorem, remember, we can only have two guarantees at the same time. So when we apply the read only pattern, we introduce the guaranty of partitioning, because now data is distributed, right? There's different parts of the data. We do have availability, because even if master goes down, we can still even read our read only replicas and we do have that guarantee. But we might lose a bit of consistency. And the reason for that is because it might take some time from whenever we wrote to master to write into the read only replica. So, if somebody reads and they get redirected to master, they'll get a different version than the one if you read any of the read only replicas. Yeah, now you don't need to implement this pattern yourself, most of the cloud services that offer a database have this under the hood, but it's good for you to know about it and explain it. The second way you could scale your database, or at least make the read operation faster, is by using database indexing. Basically, when you have a table that's very big and you need to read through it to find certain records, you can tell the database to create an underlying binary tree or a BTS tree, which is very similar to a binary tree, and you are able to apply binary search instead of a normal full table scan. So, just going back to our algorithmical knowledge, a full table scan would be just going through each one of the records, so if we have n records, the time I would need to go through them would be n. So if I have a million records, I would have to do a million read operations to find something. When we kind of restrict

to add a binary tree it'll be logarithm of n. So if n it's a million, we go from a million operation to I think 19 or 20, which is the logarithm to of n. Again, this touches on your algorithm and data structuring knowledge, so make sure you fresh that, but basically database indexing it's a way to go from kind of, you know, linear time to logarithmic time. And moving on to the last way of scaling the database, this is basically applying what we call horizontal scaling to the database. So basically, rather than having one instance that gets very big, we will spread that into four smaller independent instances, and based on a specific property, we will write a record in here or in here. That's what we call the shard key. So, let's imagine you do that with the ID, you'd basically say, you know, if the ID is between 1 and 100, then those records will live in this first shard. But if it's 100 to 200, they will go to this second shard. And the reason I added this as the last way to scale a database is because it's one of the most complex in terms of application code. Again, those solutions are very mature, they've been around for decades, so most cloud services would offer them with one click. But it will be a bit more complex in the case of sharding. And now going back to the cap theorem, in this case, we do have partitioning, but we are using either on consistency or availability. Because it will be a bit harder to really find you'll need to go to that specific shard and find that specific record. So you'll lose a bit of, you know, the speed of reading. So with distributed databases, that's pretty much an overview of the whole persistence layer, which is the last part of the backend. We've seen how all of them work, but there's one final thing we didn't touch upon yet, which is the infrastructure layer, that's all the cloud and the CICD you need.

to really deploy all those services or that service and make it a reality. We will probably make another video where we'll go deeper into virtual servers, Docker, serverless, things like Kubernetes and even infrastructure as code. But again, that would be very big. Now, if you are going for a senior front end position in today's market, you are expected to know how to at least deploy the front end application.

So this is very, very important and it's a topic that a lot of developers unfortunately don't get too much exposure to, but then you go to senior level interviews and they'll ask you both architecture and CI CD, even if you're just working on the front end at the moment. And and folks, just to underline that, uh Bogdan and I are putting a lot of effort in these videos. So if you benefited, if you liked, if you enjoyed this video and you want us to go deeper into any of those subjects and you want more videos like this one, just drop a comment, don't just watch the video, drop a comment, let us know another thing I would mention and then I have a question for you.

Uh, but it's, you know, this seems like a lot, folks. I think the best way for you not to get overwhelmed, it's to first understand what your gaps are. And this is why if you check in the comments, we have a free technical assessment where you can actually take the quiz and see the things you are missing and actually understand what's the best way to to fix your gaps. Not just by starting out and trying to learn all these concepts.

And this is where my question for you, uh, Bogden comes from. If I'm a front-end engineer, let's say I'm, let's say senior angular or senior React JS engineer, right, I've done a bit of the of the back end, maybe 10%, maybe I touched a bit of the rest API layer. And I want to transition into the full stack this year, how do I go about it? What's the easiest way for me to initiate this journey and what would be the most efficient way for me to master these concepts?

So stay within your sickle of competence and slowly increase that that that expertise that you have. Okay folks, now as you can imagine if you're looking for a senior full stack engineering position, you also need to know how to, you know, put a resume together, how to pass technical interviews, and how to answer all this stuff live. But hey, this is why we build the senior dev and if you are a JavaScript engineer and you want to level up to senior with a cleat pad, with feedback and accountability from Bogdan and I, and surrounded by a community of like-minded ambitious engineers, then definitely check out the mentorship program that we offer, software mastery, we are opening a few spots every month and if we find a fit, we might invite you in, check out the link below to see what that entails and how you can apply. And if you want, book a call with me for us to chat and see if this could actually be a fit for you. With that being said, thank you Bogdan so much and we'll see you folks in the next one.