Welcome to the new week!
For a long time, I’ve wanted to talk more about Frontend Architecture. In my projects, I always enjoyed delivering features end-to-end the most. That gave me the feeling of completing and delivering something useful for the user. There were times when I just did backend, times when I was only doing frontend, and most of the time, working full-stack.
For many years, the front end was treated as a side effect of the backend processes. Probably because initial systems were mostly about automatic processes, document workflows or calculations. Nowadays, we have more user-facing applications. Fluent User Experience and nice User Interface are values of their own. Single-page applications emerged together with frameworks like React, Angular, Vue, etc., changing the scene of our systems. More and more responsibility was pushed to the front end from the backend. Frontend applications had to be standardised and stopped being just the tip of the iceberg for many systems.
That’s why I wanted to discuss Frontend Architecture, and I’m happy that our special guest, Tomasz Ducin, agreed to discuss the current stat of the art complexity, where to draw lines, and all that jazz.
I wanted to invite Tomasz for a long time, as he’s one of the best people I know, specialising in Frontend and Architecture. He’s Independent Consultant, Architect, Developer, Speaker, Trainer. Expertise in Web Technologies & Software Architecture. Angular Devtools Contributor. Egghead Instructor.
Still, the trigger for our discussion was his great article (or actually, a rage post): What is Frontend Architecture?
That’s where we started, but where did we end? Our talk went deep into what it actually means to design a frontend architecture – and whether it should have “frontend” prefix at all. We discussed how architecture, whether frontend or backend, isn’t just about structuring files or picking tools. It’s about decisions that shape the system's core, affect its performance, scalability, and maintainability, and can be tough to change later on.
Tomasz explained that many frontend developers still think of architecture as file layouts and tool choices when it’s more about the trade-offs, like deciding on a centralised state or choosing when to use micro-frontends. We agreed that while the backend and front end have different demands, the two “camps” could learn a lot from each other. For instance, frontend devs could benefit from backend principles like domain-driven design to better understand the business problem. In contrast, backend devs could pick up on the frontend’s efficient prototyping and structuring of applications into components.
Not surprisingly, we also discussed Conway’s Law. Who knew?! We discussed the impact of various ways to structure our teams, such as cross-functional, front-end and back-end separated, etc.
One key point was the benefits of creating cross-functional teams to bridge the frontend-backend divide. Teams that work on both frontend and backend deliver features faster and communicate better, lowering the “communication cost.” It’s all about aligning with the business goal and Conway’s Law—your system’s structure will reflect the way your teams communicate. So, putting frontend and backend together in the same team creates a smoother, more user-focused workflow.
Our discussion wrapped up with a big question: do we need separate frontend and backend architectures, or is it all just architecture? What was the answer? Check in the video!
Especially since this video is free for all subscribers! Bon Appétit!
I believe this talk was a nice wrap of the common discussions and issues with frontend vs. backend responsibilities. We covered common challenges and potential solutions.
We’re thinking with Tomek about doing a deep dive on the specific topics in Frontend Architecture (e.g. micro frontends, state management, etc.), so please leave us a comment if you enjoyed it and what you would like to cover!
Check also more from Tomek:
His Polish course Architecture on Frontend (yes, it’s polished!)
Check also other webinars!
Cheers!
Oskar
Webinars:
#2 - Keep your streams short! Or how to model Event-Sourced systems efficiently
#6 - Alexey Zimarev - You don't need an Event Sourcing framework. Or do you?
#7 - Design and test Event-Driven projections and read models
#9 - Radek Maziarka - Modularization with Event Storming Process Level
#11 - Maciej "MJ" Jędrzejewski - Evolutionary Architecture: The What. The Why. The How.
#12 - Jeremy D. Miller: Simplify your architecture with Wolverine
#14 - Mateusz Jendza: Why Verified Credentials is the Future of Digital Identity!
#15 - Mário Bittencourt: Leveraging BPMN for Seamless Team Collaboration in Software Development
#16 - Papers We Love #1 - Sagas (Hector Garcia-Molina, Kenneth Salem)
#18 - Andrea Magnorsky: Introducing Bytesize Architecture Sessions!
#20 - Papers We Love #2 - How do committees invent? (Melvin E. Conway)
#21 - Michael Drogalis: Building the product on your own terms
#23 - Gojko Adzic on designing product development experiments with Lizard Optimization
#24 - Frontent Architecture, Backend Architecture or just Architecture? With Tomasz Ducin
Share this post