Hey there,

Welcome to October. Did you all forget to wake up the Green Day person again? I know, I also think it's time to retire that joke, but it's too late now. Maybe next year.

These past few weeks I've been doing some coding streams on Twitch and I have to say I'm really enjoing them. I plan to do a few more of these over the next few weeks, covering application design with Astro, SvelteKit, and Next.js. If that sounds interesting, stay tuned!

In today's issue, we'll talk about architecture, micro frontends, the design system ecosystem, and my favorite "full-stack in a box" type of book. Let's jump in.

FRONTEND ARCHITECTURE

The Important Stuff

I feel like a newsletter about frontend architecture should have spent a little bit of time defining what frontend architecture actually is, right?

But here we are, on our seventh issue, and this is the first time the subject has come up. Great job, me.

The thing is, it's hard to find a one-size-fits-all definition of software architecture (or frontend architecture for that matter) because nobody seems to agree on what exactly we mean by it. So instead of trying to define what architecture is, I find it much more productive to talk about what it is made of.

A great example of this type of discussion comes from a conversation between veteran software architects Martin Fowler and Ralph Jonhson. After struggling to find a comprehensive and general definition of software architecture, Jonhson came to the conclusion that:

"Architecture is about the important stuff. Whatever that is."

That's just a perfect definition of architecture. It's partially a joke (at least, I think it is), but it also holds a powerful insight—all we have to do is identify the important stuff in our particular project, and once we find it, well, that's our architecture.

This immediately brings up another question, though: how do we know what's really important?

My favorite way to answer this is to use the framework described in Fundamentals of Software Architecture. A core idea in this book is that any architecture (including frontend architectures) can be broken down into four components, and the combination of all of them is what gives an architecture its true identity:

• Architecture style: this is the structure of your architecture, and it's what we typically refer to as the architecture itself. There are two big categories of architectural styles: monoliths and distributed architectures (i.e. micro-frontends), but we can also break this down by rendering patterns, such as client or server-side rendering, islands architecture, server components, and so on.
• Architecture characteristics: these are the -ilities of your system (maintainability, scalability, reliability, performance, etc.), and they help answer the question, "What do I care about the most?" We obviously care about all of them to some degree, but it's helpful to define which are the most important in our particular project.
• Architecture decisions: these are the hard rules of your system, and they help determine what is and isn't allowed. For instance, in distributed frontends you'll have to make decisions about sharing code and dependencies across applications. Should you use a component library? Is copy-pasting OK? Can you reference modules that belong to other apps? (pro tip: the answer to this last one should be no.)
• Design principles: these are guidelines or recommended practices. They're much more flexible than architecture decisions, and it's up to the developer to follow the guidelines or not. DRY (don't repeat yourself) is a commonly used design principle—it's a good rule of thumb but not something developers should blindly follow at all times.

What I like about this framework is that it makes it very clear that an architecture is not a single thing, but a collection of lots of big and small decisions. It's like putting together a puzzle where we get to choose the pieces that make up the whole picture. So… I guess it's more like building with Lego blocks, right? Anyway, you get the idea.

But a framework like this one is not much use until we actually apply it, which brings us to our next point: how do you find the right architecture for your project? That's a great question, and one I'm sure you already know the answer to.

It Depends

Every project will have different architectural needs depending on three big factors: what's the product that you're building, what does the team looks like, and who your users are.

For instance, an AI startup with a small team might value agility and simplicity over scalability and performance, so they'll probably choose a monolithic architecture that would let the team move faster and with less overhead. When it comes to technologies, they might decide to use whatever frameworks and tools everyone is already familiar with, even if they're not the most efficient or the most performant.

On the other hand, a larger company building an e-commerce website might be the complete opposite. They value performance above all else, and they care about scalability and deployability (no, I didn't make this word up) because they want to prevent people from stepping on each other's toes. So they might choose to break things down into micro-frontends rendered at the edge, even if it means increased complexity and slower release cycles.

If your job is to figure out what the important stuff in your project is, then congratulations—you're an architect now. Even if your job title says otherwise, you're responsible for much more than the code you write.

Your job as a frontend architect has less to do with code and specific technologies, and much more with big-picture thinking and understanding tradeoffs. It's a hard job, and it can feel lonely at times, but it's also incredibly rewarding.

So what's the important stuff? That's for you to decide, dear architect. Hopefully, today's newsletter will make some of your decisions a tiny bit easier.

WATCH LIST

Solving the micro-frontend puzzle with fragments architecture

​Pete Bacon Darwin gave a talk at the Future Frontend conference earlier this year, sharing some fresh perspectives on micro-frontends.

His team at Cloudflare has been working on a series of strategies and techniques aimed at solving some of the main challenges of micro-frontends, such as poor performance and slow deployments. In his talk, Pete breaks down these ideas into three general concepts: fragments, piercing, and reframing.

• Fragments: server-side rendered micro-frontends that are then composed together at the edge, using Cloudflare Workers. Each fragment is deployed and rendered independently, so you get all the benefits of micro-frontends along with blazingly fast delivery.
• Piercing: a strategy for incrementally adopting micro-frontends in your existing applications. Rather than a big-bang migration, you can start building fragments for different parts of your app and then embed them into your existing legacy layout.
• Reframing: a technique for "unloading" micro-frontends when they're no longer needed. This is meant to help free up the memory used by the different fragments users load as they navigate through the app.

These techniques are still quite experimental, but they seem very promising for large frontend projects that need to be maintained by multiple teams and can't afford to compromise on performance.

If the talk piques your interest and leaves you wanting for more, Pete wrote a couple of blog posts with his team covering these ideas in much more detail:

• ​Cloudflare Workers and micro-frontends: made for one another​
• ​Incremental adoption of micro-frontends with Cloudflare Workers​
  ​

ARCHITECTURE SNACKS

Links Worth Checking Out

BOOKSHELF

Web Scalability for Startup Engineers

"A system design book in a frontend newsletter? This is surely a mistake."

A mistake? Me? Impossible!

Well, it's actually entirely possible, but I promise this isn't one. In fact, Web Scalability for Startup Engineers by Artur Ejsmont is one of my favorite books to recommend to software engineers of all kinds, but especially frontend engineers.

I like to think of this book as the missing manual of web development. It's a 300-page roadmap that will take you on a full-stack journey, from the initial user request to the database layer and back. If you're a frontend developer looking to expand your backend and data engineering knowledge, this is the book for you.

The first half of the book covers concepts you might already be familiar with, such as building a frontend and API layer, an overview of web scalability, and principles of web development. You might be tempted to skip the introductory chapters but I'd highly recommend that you don't—they're well worth the time investment.

The second half takes us all the way to the backend, covering the data layer, caching, messaging queues, and searching. These are areas we don't typically have a ton of exposure to as frontend developers, so I'm sure you'll get a ton of value out of them.

Along the way, you'll find that every concept in the book is marvelously explained with diagrams and practical examples. There is also very little code in the book, so it's a truly language-agnostic resource. It doesn't go too deep on any particular subject, but it's a great starting point for choosing areas to focus on next.

​

That’s all for today, friends! Thank you for making it all the way to the end. If you enjoyed the newsletter, it would mean the world to me if you’d share it with your friends and coworkers. (And if you didn't enjoy it, why not share it with an enemy?)

Did someone forward this to you? First of all, tell them how awesome they are, and then consider subscribing to the newsletter to get the next issue right in your inbox.

I read and reply to all of your comments. Feel free to reach out on Twitter or reply to this email directly with any feedback or questions.

Have a great week 👋

– Maxi