Every Frontend Architecture Pattern, Explained

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

What are the tradeoffs and when should you pick them? And at the end, I'll also give you a frontend architecture audit. Which is basically a checklist that you can use to make sure that you tune and you express yourself as a senior engineer in the frontend 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 reloading every time you go to a new page. The complexity is pretty low. The size of the team 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 fatight coupling between the backend and the frontend and very poor scalability. And there's also a bit of framework locking 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 frontend. 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 frontend and we start having things like state on the frontend, which wasn't the case. Now, SPAs 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, it's higher because all of a sudden you need a frontend engineer.

So basically when SPAs were born, the frontend engineer was born. Because again, we're offloading all that, we're moving all that logic to the frontend. 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, it's higher than static pages, but still very manageable. Remember, they are rich, interact 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 a 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 we move on, keep in mind this key concept which is thick client versus thin clients. Basically, a thick 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 back end more as a storage.

So, what we'll be moving from, it's 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 thin. 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 back end 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 own by the front end team, by the client. team. So all of a sudden, the front engineer also needs to know full stack.

Even more important, graphQL came to solve a lot of the problems that we had with the rest APIs, those are over fetching and under fetching. 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 plus 1 problem and thinking graphs and scalability. And so everything became a bit more complicated. The advantage is that behind the graph server, you can have many different microservices, you can have individual back end teams waking up 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 Staler endpoints, a lot of a fast iteration and aggregated services because with A back end for front end, you only need to implement authentication once.

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 the single point of failure. So, the scalability, it's slightly higher than your SPA. Performance kind of stays the same.

Actually, it's a bit lower because you have the 860 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 back end 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 SSI server side rendering appeared, and all those fancy frameworks we use today or meta frameworks around React, around view, which are Nextjs and Nextjs 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 rebuilt 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, it's server side rendering, where we take a JavaScript framework that we used on the browser, that page interactive, there's still a lot to do. And this is what Nextjs and Nxjs, all those frameworks kind of solve this problem of rendering on the server, that initial page with the 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'd get that pre-rendered 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 Vdom 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 it's still very much delayed. It still takes a long time until the users can actually interact with the web page. I mean, in the meantime, they may 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 Astrom.

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. Oh, they are basically implemented by default in the latest versions of Nextjs. So, you don't need to worry too much, but you do need to know, you're not shipping the whole component tree. solve the problem of interactivity. We solve 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 will 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 your CDN, that's very easy to scale. But now that there is server work acting to 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 it's 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 Next.js 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 our 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 SPA faster, but not a lot changed 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 and monolith comes in. With the modular front and 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 we got without someone breaking something when the codebase is it so big. So what we tried to do at that level is to add boundaries between modules. Extract our shared UI and logic, the design system, the global CSS, maybe some reusable hooks, and also extract shared services like auth, 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 are working in domain teams. And so basically everything that has to do with the 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 domain-driven 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 can literally change the snippet of the React component with a view component or with an angular component, and you have to change nothing at the other part of the code.

So basically, you have an application where you could entirely swap your front end framework, and you don't have to change the whole thing. You keep a lot of your code it's what they 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 it's, sometimes. The reality is, classic architecture doesn't apply too much in the front end because most content frameworks are already opinionated.

They come with a certain structure. The frontend is usually teen. 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 over engineering. 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 how it's only applied to very big frontend projects. or projects that, you know, will have a very long lifetime, like they'll 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 code base, 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'll be okay in 99% of the cases. Going back to the frontend Monolith, as we see, it's definitely as scalable and 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 in in practice, it's quite hard to be very disciplined about it and implement it well.

Finally, we have micro frontends. And this is where the single page application meets enterprise software. In micro frontends, 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 can 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're 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're going to 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 micro front ends 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 micro front-ends. However, we see this a lot in interviews, even smaller companies might ask you, how would you do micro front-ends? because they have a bit of FOMO and they want someone that knows how to do it.

So to make sure you know at least when do they make sense and at the high level how it actually works at a high technical level. If you want me to make a video specifically on micro front-ends 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 land it there? And what would be the next natural next steps? So you want to write down on paper, you know, are you doing an SPA? Are you doing a static page? Are you doing MVC or do you have a backend for front end? What are all the patterns that you're 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're working on, you want to go from, yeah, we just use React and Next.js 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 micro front-ends down the road.

That would be a very solid answer. And that's the kind of answers that make sure that you don't get what we call a back-end rejection. And the back-end rejection in interviews, it's 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 bit of 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 roadmap for you to really fast forward to that senior level.

Thing 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 one.