About this talk
In this talk, Jakob, a fullstack developer specializing in Next.js and a Google Developer Expert in web performance, explores the complexities of front-end architecture using analogies from Dungeons and Dragons (D&D). He draws parallels between the roles of a dungeon master and a front-end architect, emphasizing the importance of decision-making, managing trade-offs, and documenting architectural choices. Jakob outlines key dimensions of software architecture, such as performance, scalability, and accessibility, and discusses the relevance of different architectural styles like monoliths and micro front-ends. He introduces the C4 model for visualizing software architecture and stresses that understanding the 'why' behind technology choices is crucial. By sharing his insights on structuring applications with Next.js and Vue, he highlights the necessity of maintaining coherent architecture to prevent chaos and architectural drift in software projects.
Full transcript
Sure. >> Okay. Thank you. Hello View Amsterdam. It's so great to be back and celebrate this amazing event with all of you. Front end is no longer just the UI layer. It handles um caching, it handles state management, it orchestrates the API, it contains some business logic. With such complexity, it can easily became become chaos. So to control this chaos, we need to bring order to it.
And that is precisely why we need both dungeon masters in DND and front-end architects. My name is Jakob and I'm a fullstack developer specializing in next. I'm part of the KNX ecosystem team u helping core team maintain modules plugins documentation speaking at conferences sharing a good word about the framework I'm also a Google developer expert in web performance and as a hobby in my free time I
craft some great stories for my players as a dungeon master so for those of you who are not familiar with the D&D concept it's a role playinging game where a group of friends meet and the players they they role play uh certain characters such as elf wizard or halfling rogue or maybe dwarf barbarian and me as a dungeon master I focus on role playinging multiple characters the
people they meet along the way I focus on maintaining the story the adventure and also the rules themselves but before we dig deeper into Dungeons and Dragons Let's address the dragon in the room and talk a bit about software architecture. So software architecture is about decisions and quality attributes we wish we could get right early in the project. Decisions are the things that we perceived as difficult
to change over time, difficult to change while quality attributes could be performance, scalability, accessibility early, probably before the project starts. And there are four main dimensions of software architecture. And to explain all of them, I usually like to bring an allegory of a DND character class. So let's take a look at this handsome guy here. He is holding a shiny sword, wearing a big iron armor and
holding also a winged helmet. So, this guy certainly has a class. My personal favorite, he's Aldin. And he has a background, origin, personality. Maybe during the adventure, he lost a brother in a battle and he's trying to find him throughout the adventure. He has some stats such as strength, dexterity, or constitution. And finally has some skills such as the overpowered divine smite. Whoever played Balders's Gate or
DND knows what I'm talking about. Um supportive lay on hands or uh occasional divine sense. So if we compare it to software architecture, we will see that class can be converted to a style. It could be microservices, could be monolith, modular monolith, mic micro fronts. The background can be decisions basically guidelines for the team where they should go with the architecture and the The stats will convert
into characteristics. So we might have performance, accessibility, and scalability. And notice that we can't have everything at 100. We need to prioritize them. There's it's not possible to have everything from the start. And skills will move into logical components. modules, UI, design system, basically anything that will build our and in building architecture we have to take few things into consideration and those things are called architectural drivers
and this could be a team experience, could be business goals, could be functional requirements, constraints, all these things we need to take into consideration. while building our software architecture and front- end architecture to be more precise. So speaking about front- end architecture itself, let's apply those things style, characteristics, decisions and logical components for our front-end The first example we might have monolith next application for the characteristics
we want to focus on performance then accessibility and SEO for the decisions we want to go with PA for our global state management and we want to do write operations in API layer for the logical components we'll go with server components composables and stores the second example could be micro For front ends view scalability, deployability and maintenability for car decisions we will share code with layers and
compose our application client side and for logical components. Finally, we'll use models, collections, templates, views, possibly more. So every architectural decision we make is basically a trade-off. So if we can select uh global state we have to take into consideration tradeoff of convenience versus the versus coupling microrends autonomy versus complexity SSR performance versus operational front end architect role another allegory for Dungeons and Dragons because I will
be speaking as dungeon faster. So both roles have three three main um jobs or roles. Starting with um setting the direction. We need to set the direction. We need to sometimes make some tough decisions whether it's the the project and we need to select some technology or it's the journey and we need to make some tough decision for the players. Second of all, we need to analyze
the trade-offs and also take into consideration something that is called technical breath and technical depth. I will talk about it in a second. And finally both dungeon master and front end architect they do some in some way the invisible glue work which means documentation notes um meetings and guiding less experienced team members about technical breath and technical depth. You see this pyramid which is divided into three
let's say parts. The top one what you know we are here at V Amsterdam so probably for all of us it will be view or next this is our expertise our uh we specialize in view or next the one in the middle what you know you don't know if we specialize in front end in view for for us it could be like e-commerce uh CMS uh search
payment things we are aware of but we are not proficient And finally at the bottom we have what you don't know you don't know. So the things that we are completely not aware of in our everyday work. Maybe it could be Kubernetes, Terraform, DevOps cloud, you name it. So as the front- end architects, we need to focus on two uh two elements. The top one and the
middle one. We need to be comfortable with going out from the comfort zone and trying new things out and becoming proficient with it. So for modeling the architecture uh I usually use a thing called C4 model. Uh let me yeah it's still there. Um so it basically looks like this. It's a model that is sometimes compared to Google maps where we can zoom in and zoom out
to see more or less details. So we are starting with a context where we have a customer that uses our e-commerce app and our e-commerce app can connect to some kind of third party services such as CMS or payment. And if we want to go deeper and see what's inside our so-called e-commerce app, we can go to deep deeper level deeper into container level. And in this
container, we can see this that this e-commerce app it's actually composed out of static next app which is for the blog spa view for the portfolio page and maybe a next SSR app for displaying products that integrates with the API created in Nest.js. JS and using the database such as Postgrql. But let's say that we are interested in seeing what this web app actually has inside. So
we can go also a level deeper into component level and in here we will see that the web app can have like a product card component, a listing page, product fetch, maybe some kind of a module for handling sitemap and robots. And finally there is the last level for the code and in here we can um go deeper into specific element of the um component model component
level and it's called code and in here we can see the product fetch. It could be a composible and inside we'll see that it has some functions for fetching the product for getting full product price or maybe getting a product variant. So the g general rule of thumb here is that the code level shouldn't be that accurate because it probably will change a lot throughout working on
a project. However, the context level we should spend the most time here because this is the the the highest level of um architecture and in here we should spend the most amount of time because this shouldn't change after we define it. architectural decisions. Why is more important than what it doesn't matter if we choose Nex.js or next although in my opinion you should be using next. Uh
but the general rule is understanding why we're using it. Maybe we are using it because we need serverside rendering or we need performance or we need SEO. There should always be a reason why we are selecting a tool rather just rather than just following a trend or vibe. And to document the decisions, there is a great um repository and a great concept created by Michael Nigert called
decision record actually architecture decision record in short ATR. And I was using it quite a lot in one of the previous projects I was working on because we had continuous changes in how the architecture was supposed to look like and changes of the business needs. So we needed to find a way how we can easily document those things so that new joiners like new developers or maybe
supervisors of the project they can instantly see what was the decision and what are the consequences of it. You can scan the QR code. It will take you to the GitHub repository of uh of this where you can see this file. You can copy it and use it as well in your projects. I will give you a few seconds. Okay. And into architecture design specifically for Vue
and Knack because we're at Vue Amsterdam conference. Architecture is not only about code is about defining a way how teams can move and work seamlessly like smoothly and safely. So for the team of two or three people, we probably wouldn't go for microrends because it would be too complex. Um so we probably go for monolith. If the team grows to a 10 people, we might consider going
to modular, I will show you in a second how this approach works. And if the team com it's combined out of I don't know 30 people, we probably will go for micro front ends. But the thing is with the uh going right we have the bigger team size but also bigger technical complexity. So now let me show you a bit about next modular architecture. Whoever view was
here last year I was showing something similar uh in the project that I created but the general idea is that we have a very simple app. It's like a hello world and we have a app folder where we have our core application. We might have some assets, components, pages as I mentioned pure um hello world application. But we also do have local modules because next allows us
to create local modules. And in this modules, we can extract. By the way, is the font size okay or should I increase? Okay. Um so we have three main modules. The listing module, the product module, and the search module. Probably if someone is working with e-commerce, this is a common thing. So each module has some content in it. We have the configuration. So it will be a
product module. And what we do inside is we can extend pages. So we can register here in this particular module. We can register new pages, new composables or new components that will be coupled and grouped into one specific domain. That could be a product, could be a listing. So we can extend like a product page or product variant page. We can register composables and components in other
scenario in the search module here. We can also register API like server handlers if we like to and also if we want to go out from just our local uh local module. We can also do like install modules where we can basically install any kind of kn module. So we can have a uh block module where we will for example install story block next module and add
story block to our next application. Really nice for structuring your app so that it's prepared to scale and adapt to changing uh needs of the business and the project as well. Going further we have next layers and there is no better video or tutorial that you can watch by than the video from professor Ale l Alex licter who is there um it's a great tutorial about how
it works but from my side just to explain to you how it works quickly um it allows us to basically extend one application with another one. So what we can do is we can create an app layer, shared layer or specific domain layer and we can extend our main application with it. We can also use a layer created as an npm package or from a GitHub repository.
Very versatile, very very useful for um extendable architecture. But as my friend Tom Duchin once said, folder architecture is not folder structure is not architecture per se and never has been because architecture is much more. It's not only about how we name files and how we structure them in the repository. It's about the decisions. It's about the um setting boundaries, ownership and many many other things. So
it's not only about how we name files and structure them in our And if we are looking for some tools that would help us um achieve better architecture, uh these are called architecture guard guard rail rails, sorry. Um we can use a tool called dependency cruiser. It's a really nice thing that I re recently discovered. It basically allows us to create rules that certain module for example
cannot use dependencies from another module. So if you have a product page, we cannot use we cannot import for example a component from a listing module. This way it's much easier when our repository or project grows. it's much easier to maintain this the coupling of the logic and avoiding coupling the modules together uh because then it's much easier to extract them into either module layer or microontent
application. So last year Alvaro did a talk here about Tresjs how he built a Vue.js JS viewbased 3D RPG game and he invited me, Daniel and Alex to join his session where we are doing some some some in some way DND and at the end he said how amazing it would be to have a DND session here in V Amsterdam. So I decided why not. So let
me welcome to the stage Ramona Alvaro and Alex. Please give them a big round of applause. >> Hi. Good. Okay. Exactly. So, um in terms of D and D, what we usually do is before we actually go into a session itself, we create some kind of a theme so that we all get into right um mood. Let's say let me see if that Can we have some
sound or Oh, we have. Great. >> Spooky. So, the lanterns flicker as your party descends into the ruins of an ancient keep. Long ago, this place was a temple of knowledge. But now, the halls are twisted with dark magic and forgotten traps. Rumors say a powerful artifact lies somewhere within. The orb of order, a relic said to bring structure to even even most chaotic systems. But the
dungeon does not give up its treasures easily. Free adventurers step forward into the darkness. So starting with Ramona. Ramona today will be Mera, the half elf wizard. A brilliant spellcaster whose curiosity often leads the group into strange situations, but her mastery of magic has saved them many times. Years of studying ancient arcane systems have sharpened her instincts. Going further, Alvaro, who is right now drinking. Uh, we
have Dorian, the Tiffling Rogue. Quick, clever, and always watching for hidden dangers. Dorian is is used to working in shadows and navigating traps that would stop most adventures in their tracks. And finally, Alex will be Kyle, the human paladin, my favorite. A battleh hardardened knight sworn to protect his allies and face danger head on. Kyle believes that courage and strength can overcome any obstacle standing between the
party and they call. So we know our characters. We know a bit of the story. Now we'll move into the first scene. The first scene is for Kyle, for you, Alex. As you move deeper into the Sorry, I forgot one thing. These are the players. Um, so the first scene for Kyle, as you move deeper into the dungeon, the corridor suddenly collapses ahead of you. A massive
stone pillar has fallen across the path, blocking the only way forward. Dust fills the air. That's good, Ro. Uh, the rest of the party looks to Kyle, the only one strong enough to move the obstacle. What do you do? >> Well, I want to use my strength to move >> That's a good answer. Um, so how does it work right now is that Alex will roll roll
the dice, the d20 dice and you will add your strength and proficiency modifier which will be plus seven to the score and you will tell me the result and I will tell you what happened. >> Okay, wish me luck, guys. Otherwise, we we're stuck in the corridor forever, right? All right. So, I rolled a 10 plus seven is a 17. >> Oo, nice one. You plant your
feet and push all your with all your strength. With a grinding sound, the pillar rolls aside, just enough for the party to squeeze through. The path forward is clear. So, we move on to Meera. Now, >> this one. As the party moves deeper into the dungeon, the air suddenly grows cold. A crack of blue lightning flashes across the chamber and a creature, a pure creature of pure
arcane energy forms before you. A living spell. I said at the beginning that players can also roleplay multiple characters as you have seen. A living spell, a swirling mass of unstable magic, floats above the ground, crackling with power. The creature turns towards the party. But Meera has studied magic her entire life. Creatures like this are dangerous, but not unfamiliar. What do you do? >> Well, I take
a little moment to think and will cast a shield spell. >> What? >> Shield. >> Shield spell. Okay. Don't you want to smack it with >> lightens? >> It's an 11. And I guess there are some modifiers. >> Uh yes, but before that as you are proficient with magic, we'll do a bit modification here. If you are proficient with it or experience with it, you will roll
with so-called advantage, which means that you will roll dice twice and take the better result. >> All right. So, let's see what's the next 11 again. >> Okay. consistent uh plus seven because it's still it's 18. You raise Okay, let's say that your shield also fires missiles. You raise your hand and there is a precise bolt of magic. Your spell pierces the creature's unstable core and the
living spell shut shatters, then collapses into harmless sparks of fading energy. The chamber f fall falls silent once again. And we have our final player. This is the animation by the way. This the shield, right? And we have finally Dorian. That was a bit of spoiler. At the end of the dungeon, the party finally reaches a massive iron chest. Ancient symbols mark it as the resting place
of the orb of order. But something isn't right. Thin wires and tiny metal plates surround the lock. A deadly trap designed to punish anyone careless enough to tamper with it. Even for experts such as Dorian, this looks dangerous. Dangerously complicated. What do you do? Don't mess it up, man. >> Let me find my dexterity. >> Hey, I have the key. Can I use AI for it? No,
you can use this key. >> I can use this key. It's a lockpicking set. Nice. >> Okay. So, I guess some dexterity here. >> Mhm. >> So, uh any advantage? >> H you have disadvantage. >> Oh, >> because it's dangerous. So, it means that he will need to roll twice and take the worst result. >> He has a lockpicking set. Exactly. >> Yes, but it's dangerous. >>
I don't do anything against that. >> I like danger. Where is Daniel? Daniel has more luck. Where's Daniel? He rolled. Come on. You can also roll a 20. Let's go. >> Come on. Come on. Oh, five. Okay, that can't that can go worse. >> Seven. >> So, five. >> So, five, unfortunately. >> But you get like modifiers. Come on. It's not just a five. Five plus. >>
It was plus seven, but it's still not enough. >> Unfortunately, >> your pick slips for just a moment. A sharp metallic snap echoes through the chamber. Hidden darts shoot from the walls and the lock jams shut. The chest remains sealed and the dungeon reminds you that even experts sometimes fail. That will be the end of our small adventure. Give a round of applause for our players. >>
You can stay, you can go, whatever. >> Sounds like a typical migration story if you don't plan well enough. So next time bring your lockpicking set for like expert level. >> That's a good one. >> We did all the hard work just so that the one guy can fail. >> Amen. >> No shame on you. It's It's okay. More luck next time in your new job. >>
In your new job. >> Big applause for Yakob for this amazing round. >> Thank you. >> So that was certainly fun. And the thing was, have you seen some similarities between doing the session here and doing front-end architecture? This is a strange question because if you think about it, host a session here for all of you taking into consideration the time constraints that I have 30 minutes
for the whole talk. The players might have completely different experience. not experience uh ex um yeah could be experience with DND and also that I wanted to do this session here so we had goals times constraints and experience but we made it and it's the same with front end architecture if we take those cons the those constraints into consideration we are able to do I will thank
you music can go um but speaking of fun last Here Alvaro did a talk about TJS. I told about it already. And since then both me and Alvaro were experimenting in trying to build uh Okay, I see there should be a video but it doesn't play. I will show it in a second. Uh so we were experimenting in trying to build a 3D RPG game with the
project he created the Tresjs. So here you can see the screenshot of what Alvaro is doing. So building characters, building some kind of UI which is similar to Baldor's gate game. However, in my case, I went in a bit different way. Hope you can see at least something But I recently implemented the collision system which was so much fun because I was doing it without any AI.
I was just trying to figure out how it could work and it made me so much fun to basically build those things. If you haven't tried Tresjs yet, I highly encourage you to do so because it's an amazing project created by Alvaro. You can build from like 3D scenes, games, basically anything, anything you like. Okay. Um, if you'd like to stay in touch with me, find me
somewhere. You can do so by searching for Jacob Andreski. I have a blog, I have an ex profile, I have a YouTube channel as well. And if you'd like to see uh my open source work, you can go to barosium in GitHub. Uh, on the blog I'm posting weekly about view next and performance, probably similar concept we discussed today. And if you like to learn more about
front-end architecture, there are two resources that I I can highly recommend. Starting with front-end architecture course by Maxi Ferrera, fundamentals, really good one. And also a huge guide from Tom Duchin, the guy I mentioned earlier about what is front-end Few final words, we are closing. Systems don't break, they drift. There is a term in architecture called architectural drift which basically it's not about a single PR that
makes the architecture worse. It's about those small ones, those small ones that we are adding constantly because we don't care, we don't have time, we don't focus So with that in mind, um it can become chaos as I mentioned in the in the very beginning. So the only way to like fix it is to bring order to it as I mentioned. So I small note to you
be the dungeon master your application deserves. That will be all from my side. Thanks for having me and enjoy the rest of the
