Frontend to system, a nie "kodzik" | Tomasz Ducin

👉If this episode resonated with you and you want to take things beyond just "using AI," we have good news for you! Check out the new Developer of Tomorrow training: https://developerjutra.pl/?utm_source... Is your interface a trash heap of optional fields? It starts innocently enough – one common model for list and edit, because after all, they're the same entity. But a year passes, and suddenly you're afraid to touch any interface because your app has switched to append-only mode, and the number of optional fields has exceeded the limits of decency. In this episode, we show that the problem isn't React, Angular, or Redux, but the erroneous assumption that the frontend is just a "code" for displaying data. You'll learn why noun-based modeling is a trap that leads to project paralysis, and how switching to business process thinking can save your architecture (and your sanity). About the Mentor Tomasz Ducin is an experienced software architect and engineer who has worked for years at the intersection of development, system architecture, and business. He focuses on topics that truly matter to IT: understanding systems, making architectural decisions, and consciously using technology. Architecture Isn't Just the Backend We often think that design patterns and architecture are the domain of the backend, and that on the frontend, all that's needed is to choose the right library for the state. This is a mistake that pays off for years. This material is a bucket of cold water for anyone who feels that the framework is starting to dictate terms, and data synchronization between views is becoming a tilt at windmills. Learn how to view the frontend as a system that should support the business, not just mindlessly push JSON from the server to the screen. Table of Contents 00:00:00 How do you divide your application into modules? 00:01:18 Frameworks and libraries - do they really dictate our architecture? 00:03:00 Key aspects of front-end design: from Conway's Law to Read Models. 00:04:50 The trap of a single model for everything and the regime of "optional fields." 00:07:25 When is one model not enough? A turning point in system development. 00:08:09 What are heuristics and how do they help in making design decisions? 00:09:02 Heuristic 1: Business goal instead of nouns. 00:09:24 Heuristic 2: Actor - who uses this data and why? 00:10:37 Conway's Law in multi-team practice. 00:12:42 The problem of data synchronization between modules - is redundancy bad? 00:14:40 Frontend integration patterns: Events and Pubsub. 00:16:04 Vertical Slices - a step further in separation of responsibilities. 00:17:14 Summary: You change the code in a week, but the system takes years to recover. What questions does this episode answer? 💡 Why is sharing a single TypeScript interface for different views a sure path to disaster? 💡 How can you avoid "append-only" mode in data models where everyone is afraid to delete anything? 💡 Are Redux and a centralized store always the best idea for data consistency? 💡 How can you recognize when to duplicate the model instead of extend it? 💡 What are architectural heuristics and how can you use them to assess code quality on the frontend? 💡 How can you synchronize data between independent modules without creating tight coupling? In this episode, you'll learn: ✅ How to think about business functions instead of focusing on entity names. ✅ Why "state denormalization" on the frontend can be your ally, not your enemy. ✅ How to use events to communicate between loosely coupled parts of your application. ✅ What's the difference between a "code-based" approach and a system-based approach, and how does this impact technical debt? ✅ How to ask business questions to predict changes in data structures before they happen. ✅ Why a framework's API (bumps, signals, streams) shouldn't dictate your architecture. ✅ Why state management in React/Angular is more than just a library. ✅ How to properly divide your application into modules on the frontend. ✅ When code duplication (DRY vs. WET) is better than flawed abstraction. Learning about read models and heuristics is just the tip of the iceberg. Each of our materials is as substantive as this one – if this way of thinking about architecture resonates with you, there's a high probability that you'll be delighted with the next ones. We put a lot of energy into creating this content, so take advantage of it – especially since it's completely free. Check out these materials too: ▶️ Will AI replace programmers? | Tomasz Ducin    • Czy AI zastąpi programistów? Rzeczywista r...   ▶️ Why aren't seniors good at AI? | Kuba Kubryński    • Dlaczego Seniorzy nie umieją w AI? | Kuba ...   ▶️ Are programmers at risk from AI? | Jakub Kubryński    • Czy programiści są zagrożeni przez AI? Pra...