Every Frontend Architecture Pattern Explained in 23 Minutes transcript

Senior front-end interviews are not about coding. They are about architectural trade-offs. Do you know the difference between a monolith and microrends? When would you use a clean architecture versus an hexagonal architecture? Would you set up server side rendering or a static site generation? And if you struggle here, you'll end up sounding midlevel at best. In this video, I'll walk you through the evolution of front end architecture from static pages to MVCs to single page applications, backend for front ends, modular monoliths and microrends.

What are the trade-offs and when should you pick them? And at the end, I'll also give you a front-end architecture audit, which is basically a checklist that you can use to make sure that you think and you express yourself as a senior engineer in the front end interview. Before we start, how did we even got there? Well, the web started just as static HTML and CSS with tiny scripts, just a sprinkle of JavaScript, super fast, but zero interactivity.

And this really looked like magazines. You can think of it as a newspaper. Just text and images, but zero interaction with the user. And that's why the first architecture style came in, which was the model view controller. Pretty much all big web frameworks implemented MVC in the beginning including Django, Ruby on Rails.net. Basically in the MVC model, what we do is that we still create that static view. We still create our HTML and CSS, but we do it with a model and a controller that run on the server.

So we use a server language like PHP or Python or Java to mix together certain elements and data and then spin out that tailored HTML. Basically the MVC allows you to create better, more interactive web pages, but it's still very poorly scalable. The performance is not so great and you need to reload every time you go to a new page. The complexity is pretty low. The size of the thing that people can work on, it's also pretty low.

And again the product value comes from the fact that everything is dynamic and you can implement more complex logic than in static pages but it comes with very tight coupling between the back end and the front end and very poor scalability and there's also a bit of framework lock in because it's extremely hard to switch from one of those frameworks to the other. Now the MVC really revolutionized the web in the early 2000s but then JavaScript happened and basically the revolution of the single page application started.

Now you probably worked with a single page application where you have your spa written in React View Angular or any of those frameworks and then you have some sort of a backend API which is our old view but now it's a model view. Basically, we just use it to fetch data, but a lot of our logic moves to the front end. And that gives the web page a lot more interactivity because you can request data and make changes without reloading.

So, we move authentication, validation to the front end, and we start having things like state on the front end, which wasn't the case. Now, SPA are great and they definitely scale a lot better. They have better performance, especially when it comes to interactivity. They're very fast because you don't need to navigate to a new page. The complexity is higher because all of the sudden you need a front-end engineer. So basically when SBAs were born, the front end engineer was born because again we're offloading all that.

We're moving all that logic to the front end. You can have a bigger team and a lot more product value. So when JavaScript frameworks appeared, you start having this complex products like dashboards, very complex apps and basically product companies that were building web products which was pretty new. And this was all enabled by those frameworks. Now the cost is higher than static pages but still very manageable. Remember they are rich, interactive, very scalable.

They can handle complex state management. So you have a lot more product value, but there's too much JavaScript and usually you get a very poor loading time because all of the sudden the browser has to parse and download all that JavaScript to be able to show something. And because you get this initial empty page, you also have very poor SEO. Now before we move on, keep in mind this key concept which is thick clients versus thin clients.

Basically a thin client would be your static page that delegates most of its logic to the back end. Whereas a thick client, a fat client would be one that has a lot of logic and a lot of business logic and it's using the backend more as a storage. So what would be moving from it from thin clients to thick clients by adding more and more logic to them. There's different advantages and disadvantages of having that logic on the front end.

I will not get too deeper into it, but do make sure you understand the difference and to what extent should your client be thick or teen. Now, with single page applications, we only solved part of the problem. And as the web grows and grows, we start having mobile devices. And with mobile devices, we have new clients, all of them requesting the same API. And that's when the BFF pattern appear which is the back end for front end.

So basically with the back end for front end we split our back end and each front end application gets an individual back end. So they don't share the same one. And the reason for this is because a mobile application has totally different views and so it might request the same data but in a different shape than a desktop application. And if you try to put all that in a single backend application or in a single API interface, it will be a Frankenstein.

So it's much better to separate them. Why is this important for you as a front-end engineer or a full stack engineer? Because most of the times the back end for front end, it's owned by the front-end team, by the client team. So all of the sudden the front-end engineer also needs to know full stack. Even more important, GraphQL came to solve a lot of the problems that we had with REST APIs. Those are overfetching and underfetching.

And although it's a very good tool, it also added new complexity for us because when building a graphql server, you need to worry about the n plus1 problem and thinking graphs and scalability and so everything became a bit more complicated. The advantage is that behind the graphical server you have many different microservices. You can have individual back-end teams working of those services and releasing software every day.

And at the same time the front-end team can work uninterrupted on their own features. So all of a sudden you could scale in terms of people. You could build much bigger teams and much more complex products. So the back end for front end would give you the tailor endpoints uh a lot of a faster iteration and aggregated services because with a back end for front end you only need to implement authentication once you only need to implement HTTPS handshakes once.

You do it with the back end front end and then you're okay with any service that's downstream but at the same time you have tie coupling and you have scalability limits and it becomes a single point of failure. So the scalability it's slightly higher than your SPI performance kind of stays the same. Actually it's a bit lower because you have this extra trip to the network because we added this new piece in between. the complexity is higher but you can grow your team and so you can build much better or bigger products and that's why the product value it's bigger than with the spa now the upfront costs also increase because you have more infrastructure to run and you have a lot of learning you need to make your team kind of adopt graphql so that's usually a huge upfront cost now we did solve the backend problem but there's still a problem on the front end that we didn't really talk about which is the fact that single page applications ship way too much JavaScript and users are staying at an empty screen without too much happening.

So how can we solve this? Well, that's when SSG, ISG and SSR serverside rendering appeared and all those fancy frameworks we use today or meta frameworks around React around Vue which are Nex.js and Nox.js and the like. Basically what we do with SSG which stands for static site generation is that we are going back to the future actually back to the server and we generate static pages. So whenever you don't need interactivity in the front end you can still use react or a modern framework but in the end ship to the browser static pages that you host in a CDN which is a content delivery network and so it's blazing fast.

Again, this has very little interactivity and you cannot really update your content unless you rebuild and redeploy your website. So, it definitely comes with disadvantages, but again, it's blazing fast and very cheap. Basically, we're back to that initial web, but with all the modern tooling and modern frameworks. The evolution of this would be incremental static generation, which is ISR. In ISR, you basically regenerate pages based on a TTL, a time to live.

So if users make a request and it's been over a certain time window, then you can go back to your data store, content store, regenerate that and replace it in the cache in the CDN. This allows you to change your content dynamically. So if somebody updated that content in the database, then the regenerated page will contain that update better than SSG, but still not good enough for us to build anything interactive. And so the next approach is server side rendering where we take our JavaScript framework that we used on the browser but now we run it on the back end.

We pre-generate our initial HTML and we send it pre-rendered to the client and so the users are not staring at an empty page. They really get something. The problem here is for us to make that page interactive, there's still a lot to do. And this is what Next.js and NoxJS, all those frameworks kind of solve this problem of rendering on the server that initial page with initial state and sending it pre-rendered to the browser.

However, to finish the story, we'll still need to end up downloading our SPA code and somehow make our initial pre-rendered HTML interactive. And the way we do that is with hydration where you get that pre-render HTML. The browser would render that. The user will see something, but then we download our JavaScript bundle. We run, you know, we execute our JavaScript framework that will build maybe a virtual DOM in the case of React.

And then we hide it. We attach the pre-rendered HTML with the internal component structure that was rendered by React. We did solve this problem of seeing something very fast on the screen, but interactivity is still very much delayed. It still takes a long time until the users can actually interact with a web page. I mean, in the meantime, they might click on buttons and nothing will happen, which is not ideal. And that's where the last stage of evolution comes, which is using tools like React server components, where you will strip down your component tree from all the components that do not have any interactivity.

So your tree on the server will be the original one, but your tree on the client, your component tree will be much smaller. And so in that way, you ship a lot less JavaScript and you are able to have even faster interactivity. So the users can interact with the page much much faster. You literally only ship JavaScript you need. There's different philosophies that follow this. And you have the island architecture. I won't touch on that.

That's from AIO. A very interesting thing. But for now, if you can explain React server components and know how to use them, when to use them, that's more than enough. Uh they are basically implemented by default in the latest versions of Nex.js. So you don't need to worry too much, but you do need to know you're not shipping the whole componentry, but only parts of it. And that's what solves the problem of interactivity.

We saw all these different ways of improving the performance of our SPA. And as you see, this is literally the most performant way to build applications that we know. It will increase your SEO. It'll load very fast. In terms of scalability, it's less scalable than an application that is client side rendered because if you just have assets that you ship to CDN, that's very easy to scale. But now that there is server work, right, into pre-rendering all this, then you need more complex infrastructure and more expensive infrastructure to make this happen.

The complexity it's extremely high. All this technology comes at the price of knowing a lot more. It's harder to on board developers. It's very framework opinionated. So whenever they change a version, you need to adapt. And so in general, the cost is higher, but you get more product value if you have a use case that needs performance or SEO, like for example, e-commerce. I know a lot of companies that migrated to Nexus prematurely and now they are rolling it back.

So be careful. Only use this if performance is really a bottleneck in the product. Now, I mentioned a lot of different terms that I've been throwing around. If some of them are unfamiliar or you feel like you have certain technical gaps, take a free technical assessment. We build it with real interview questions and you can literally find your gaps and where you are in the spectrum to senior. Check the link in the description.

Now, we've been talking a lot about web performance, how we made our SBA faster, but not a lot change in the single page application itself inside it. And as it got bigger and bigger, we need a new way to handle it. And that's where the modular front-end monolith comes in. With the modular frontend monolith, our SPA got so big. Now, to give you an example, I've worked on client applications where we had 300 developers contributing to the same codebase.

It's extremely hard to maintain code quality and keep shipping without someone breaking something when the codebase is so big. So, what we try to do at that level is to add boundaries between modules. You can basically extract our shared UI on logic, the design system, the global CSS, maybe some reusable hooks and also extract shared services like art, data fetching, logging and analytics. All those things are shared and maintained by what they usually call the platform team or the front-end platform team.

But then the actual developers that are building features, they're working in domain teams. And so basically everything that has to do with user, we will isolate that in the user domain. and then in payments and obviously our folder structure would follow that. This is one of the ways to really quickly put some order in a big single page application monolith. To implement this we can draw ideas from classical software architecture and the most common one you probably heard about it's clean architecture.

The problem with clean architecture is that it's very abstract and is very optimized for the back end but you can think of it as domaindriven architecture. And to give you an example in React, you would basically try to extract from your application the most generic entities like a user, product, whatever your business case is and then make everything else depend on them but keep those stable. What does that mean? Well, in practice your code will look a bit like this where at the very top we have our domain that's our user but then we create use cases repositories and finally our infrastructure layer our framework layer depends on that.

What's the beautiful thing in this code example? You could literally change the snippet of the React component with a view component or with an angular component and you have to change nothing but the other part of the code. So basically you have an application where you could entirely swap your front-end framework and you wouldn't have to change the whole thing. You keep a lot of your code is what you call stable. Now is this really relevant in the front end?

Have you ever seen an application that implements clean architecture? Well, the short answer is sometimes. The reality is classic architecture doesn't apply too much in the front end because most front-end frameworks are already opinionated. They come with a certain structure. The front end is usually thin. you don't start from scratch and you don't have all that logic that usually we have in the back end and yes it is useful if you change framework but how often during the lifetime of a project you'll actually have to change framework I mean maybe some projects that are very long lived will have to but most projects will not have to and so investing in those abstractions to make that possible it's usually just overengineering and finally it is good for you because it helps you think about how decoupled code would work so as a mental exercise it's very good But be very careful.

I would only apply it to very big front-end projects or projects that you know will have a very long lifetime like they will be around for the next 15 years. Another version of classical architecture is the hexagonal architecture which is more focused around how you connect external dependencies into and how you plug them into your domain. I won't detail on it because again all those ideas are very much in the back end but they're not so relevant in the front end.

But do keep it in mind. Again, they are all based on this idea of onion architecture where at the center of the onion, you have the most stable part of your codebase, which is your business domain. In reality, if you're working on the front end, you'll probably use a framework. And here's an example of how Next.js, it's quite opinionated on how you should structure your code. And if you follow that, you'd be okay in 99% of the cases.

Going back to the front end monolith, as we see, it's definitely as scalable as our single page application. We can work with a much bigger team, but there's definitely a price of complexity and cost because you do get this cohesion and we have a global state. There's a very long build time and it's very hard to really enforce those boundaries. So, it's extremely easy to draw some domains and pretend people will stick to that.

But in reality, you end up with dependencies all over the place. So, the idea sounds good, but then in practice is quite hard to be very disciplined about it and implement it well. Finally, we have microrends and this is where the single page application meets enterprise software in microrends. We literally take those domains and we deploy them as independent applications and then we put them together at runtime. So basically the the users, the header, the footer, all those things could be independent front-end applications and then there's a shell component that takes them all and put them together.

And the shell has kind of the shared CSS, the shared state that will then inject in those frameworks, but that will inject in those other applications, but they are all on different domains. The teams working on them are independent and they can deploy code independently. And that makes it possible for a lot of developers to contribute on the same front-end application. Again, it's a very cool concept, but it requires more technical investment and there's more moving parts and a lot more complexity.

And so the way this will look in reality is that you can look at your web page and kind of split it by teams and those teams will have vertical slices where they own the back end and the front end part of that and they're all independently deployable. So everybody works in parallel. When you have a big company with thousands of engineers working on the same client application, you need to use micro frontends. But if you're a small company and you go into this, you will basically shoot yourself in the foot because there's a lot of complexity and you'll actually be slower, not faster.

So keep in mind that microrends are very scalable in terms of development speed. You can have a lot of people contributing on it, but performance will suffer because we're putting all those applications together when the user lands on the page. You can use things like Webpack module federation for that. But you do have a decrease, a slight decrease in performance. The complexity is really high, but a huge team of developers can work in parallel.

So if you manage that complexity, if you have very great engineers, then yes, you can expand your team size. The product value is extremely high because you can build things that weren't even possible on the web like huge e-commerce store or complex software like image editing or video editing but the cost it's extremely high too. So it's only in very big companies with very mature projects where it makes sense to really invest in microrends.

However, we see this a lot in interviews. Even smaller companies might ask you how would you do microrends because they have a bit of FOMO and they want someone that knows how to do it. So do make sure you know at least when do they make sense and at a high level how it actually works at a high technical level. If you want me to make a video specifically on microrends and the underlying technology let me know. And finally what I've been promising you which is the extra architecture audit so you make sure that you can stand out in the senior interview.

Basically what you want to do is to sit down and research your current codebase and the question you want to answer is what is your current architecture style? Why did you landed there? And what would be the next natural next steps? So you want to write down on paper you know are you doing an SBA? Are you doing a static page? Are you doing MBC or do you have a back end for front end? What are all the patterns that you are using right now?

And you can refer back to this picture and see how many of those or which one of those you're using. Now finally in your next interview whenever they ask you about the project you're working on or the application you are working on you want to go from yeah we just use React and NextJS to a senior answer that will look more like this. We serve static pages via static site generation and use SSR for personalization but then we structure our repo as a modular monolith as we scale we did consider microrends down the road.

That would be a very solid answer. And that's the kind of answers that make sure that you didn't get what we call a back-end rejection. And a back-end rejection in interviews is when they tell you it was all great, but then a couple of days later you get a generic email that says, "Yeah, we really liked you, but we ended up picking someone with more experience or, oh, we found someone that was just a better fit, but we will keep you in our list of candidates, blah blah blah." So those kind of things happen, not because you did anything wrong, but you haven't done enough of the right stuff.

Now, if you do want to learn more about how to stand out as a senior in the current job market despite layoffs and AI, make sure you check out the free training. There's a couple of the mental models that I mentioned that are also being mentioned there and how you can plug them in as a road map for you to really fast forward to that senior level, think like a senior, and also get a senior level job with a senior level salary.

As for me, I'll see you in the next