Software Architecture for Web Developers E-Book

Mihaela Roxana Ghidersa

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 163

Veröffentlichungsjahr: 2022

Beschreibung

Large-scale web applications require you to write code efficiently following business and architectural considerations. They require web developers to understand the impact of their work on the system and how they can evolve the product.
With this handbook, every developer will find something to take away. This book will help web developers looking to change projects or work on a new project in understanding the context of the application, along with how some design decisions or patterns fit better in their application’s architecture. It acts as a guide, taking you through different levels of professional growth with a focus on best practices, coding guidelines, business considerations, and soft skills that will help you gain the knowledge to craft a career in web development. Finally, you’ll work with examples and ways of applying the discussed concepts in practical situations.
By the end of this book, you’ll have gained valuable insights into what it means to be a web architect, as well as the impact architecture has on a web application.

Leseprobe

Software Architecture for Web Developers

An introductory guide for developers striving to take the first steps toward software architecture or just looking to grow as professionals

Mihaela Roxana Ghidersa

BIRMINGHAM—MUMBAI

Software Architecture for Web Developers

Copyright © 2022 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Associate Group Product Manager: Pavan Ramchandani

Publishing Product Manager: Aaron Tanna

Senior Editor: Aamir Ahmed

Content Development Editor: Divya Vijayan

Technical Editor: Simran Udasi

Copy Editor: Safis Editing

Project Coordinator: Sonam Pandey

Proofreader: Safis Editing

Indexer: Rekha Nair

Production Designer: Roshan Kawale

Marketing Coordinators: Anamika Singh and Marylou De Mello

First published: October 2022

Production reference: 1230922

Published by Packt Publishing Ltd.

Livery Place

35 Livery Street

Birmingham

B3 2PB, UK.

ISBN 978-1-80323-791-6

www.packt.com

“How long can you afford to put off who you really want to be? Your nobler self cannot wait any longer. Decide to be extraordinary and do what you need to do now.” - Epictetus

Contributors

About the author

Mihaela Roxana Ghidersa is a software developer who has a passion for technology. She enjoys building and delivering quality while trying to have fun as much as possible. She is willing to learn from others and share her knowledge, which has guided her to become a Microsoft MVP. She has been raised professionally by the community through conferences, training, and sessions, and she is trying to pay it forward by speaking at conferences, writing, and mentoring. She is perceptive and innovative, not afraid to exploit her best version and go the extra mile outside her conventional comfort zone. This exact desire to get out of her comfort zone has led her in recent years to switch from full-stack, frontend API design to technical leadership and architecture.

To everyone who inspired me and gave me the courage to be more. Thank you. I’m still learning.

About the reviewer

Daniele Serfilippi is a senior software engineer and architect with decades of experience in designing and building enterprise-level web applications. His passion and dedication have led him to important roles such as head of engineering and deputy CTO at international companies. He’s also an instructor, mentor, content creator, and community builder. He shares content daily with his tens of thousands of followers about software engineering, software architecture, and the JavaScript ecosystem. 

His continuous learning mindset constantly drives him to improve his skill set, experiment with new technologies, and explore new fields, such as machine learning, blockchain, and Web3. 

His mission: design apps that improve and empower people’s lives. 

Table of Contents

Preface

Part 1 – Getting the Grasp of Architecture

1

The Role of Architecture

What is architecture and why is it so important?

Can we define software architecture?

Requirements

Maintainability and extensibility

Response to change

Practicality

Quality attributes

The impact of architecture

Development-level benefits

Application-level benefits

Understanding the role of stakeholders

Summary

2

Diving into Some Common Architectural Patterns

Architectural patterns

Choice of technology

Quality patterns

Where did it all start?

Architectural style versus architectural patterns

Architectural styles

Architectural patterns

Common patterns

The layered pattern

The client-server pattern

The Model-View-Controller pattern

The microservices pattern

The CQRS pattern

UI patterns

Summary

3

Myths about Architecture

Myth no.1: Architecture never changes

Predicting the future is hard

Myth no.2: Only the architect cares about architecture

Myth no.3: Architecture is not about coding

Switch roles – collaboration

Pair programming

PR reviews

Architecture unit tests

DevOps quality gates

Summary

4

Discussing What Good Architecture Is

Consider how your application can scale in time

Horizontal versus vertical scalability

Provide good performance step by step

Is your architectural approach reliable?

Ensure security at all levels

Create a testable architecture

How do you know that your app is usable?

Summary

5

Design versus Architecture

What is design?

Discussing design patterns

Design principles

How do design and architecture work together?

Summary

Part 2 – Architect: From Title to Role

6

Types of Architects and Their Focus

Enterprise architects

System architects

Solution architects

Application architects

Software architects

Summary

7

Leveraging Soft Skills

The role in the team

Coaching

Effective communication

Collaboration

Stakeholder management

Decisions and risk management

Summary

Part 3 – From Developer to Architect

8

Who Codes and Who “Architects”?

The skills of an architect

Team dynamics

Strategic thinking

Pair programming

Summary

9

Break the Rules

Why is it essential to have a mentor?

How can you become a craftsman?

Summary

Index

Other Books You May Enjoy

Preface

This book came from a need I had at the beginning of my career: the need to know what it means to build a product from a high level to the details. Web developers often limit themselves to the daily job of coding. They start looking at the application architecture, design, and evolution only if they are lucky enough to find good mentors or the right circumstances in the company that encourage them to grow. I want this book to bring value to every web developer who wants to go to the next level in their career and to be their go-to guide.

Who this book is for

I intend to create a guide for both web developers that aspire for an architect role and web developers that, even though they are not pursuing such a role, want to become better professionals and understand the role and impact of good architecture in their projects.

If you are an architect, I hope that after reading this book, you reconsider the relationship with the development team. If you are a developer, I hope that between the pages of this book, you find knowledge, business insights, technical best practices, and ideas that will push you to improve your work.

What this book covers

Chapter 1, The Role of Architecture, looks at how, day by day, we do our tasks without realizing that we are building toward architecture. We need to understand how many benefits good architecture brings and how damaging lousy architecture can be. What is the impact of architecture on the other stakeholders besides the development team? We bring light to all these matters from the beginning.

Chapter 2, Diving into Some Common Architectural Patterns, discusses how no matter whether we are in the early years of our career or pursuing a career as an architect, as long as we build an application, we need to understand what we are building, what patterns we are creating, and why some decisions were made. This chapter covers some of the most common architectural patterns.

Chapter 3, Myths about Architecture, destroys some of the myths that web developers meet or create along the way regarding the architect and the architecture.

Chapter 4, Discussing What Good Architecture Is, covers some essential characteristics of good architecture. We will explain them one by one using relevant examples.

Chapter 5, Design versus Architecture, compares and explains an application’s architecture and design since we often confuse them. We will also point out how they work together.

Chapter 6, Types of Software Architects and Their Focus, divides and discusses different types of architecture and architects depending on their focus and level: for example, business, tech, or combined.

Chapter 7, Leveraging Soft Skills, focuses on the primary soft skills we need to develop to do a great job as an architect and meet all the requirements. Having a role where you interact with so many stakeholders creates a great need to develop skills such as time management, prioritization, communication, and so on.

Chapter 8, Who Codes and Who “Architects”?, focuses on collaboration. Whether we talk about collaboration at the business level or in the team, or about experienced web developers, juniors, architects, or technical leads, the application is built by working together and collaborating.

Chapter 9, Break the Rules, discusses self-discipline and engagement in the process. We will also open the discussion about software craftsmanship and related principles that help a web developer become an expert.

Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://packt.link/p3YMu.

Conventions used

There are a number of text conventions used throughout this book.

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Select System info from the Administration panel.”

Tips or Important Notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Software Architecture for Web Developers, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Preface

Part 1 – Getting the Grasp of Architecture

Upon completing this part, you will have a more precise understanding of the architecture’s role, its impact at all levels, and who the stakeholders are.

This part comprises the following chapters:

Chapter 1, The Role of ArchitectureChapter 2, Diving into Some Common Architectural PatternsChapter 3, Myths about ArchitectureChapter 4, Discussing What Good Architecture IsChapter 5, Design versus Architecture

1

The Role of Architecture

The tech stage has erupted in the last decade. We now work on some of the most complex systems ever. As users, we need the flows in our applications to be fast. Almost all our actions happen on our phones or online, from socializing and entertaining ourselves to paying bills and making medical appointments. At the same time, many of the applications we use are monetized, so we need features to create the best content. On the other hand, from the cars we drive to the houses we build, everything has some features that implement AI, IoT, or some kind of application that automates specific actions. From the database to the code, from functionality and user interaction to how systems are organized, we are faced with challenges at every step in the development process of a product. More than ever, it is essential to understand what we have, what we can build with our information, and what our end goal is. This is how the need for a structure arose, and it became increasingly important to create systems that could evolve while maintaining the balance between business and tech requirements.

In this chapter, we will cover the following topics:

What is architecture and why is it so important?The impact of architectureUnderstanding the role of stakeholders

What is architecture and why is it so important?

If you ask a group of developers what kind of architecture works for them, you will receive many different responses reflecting each person’s experience. Architecture is a term used to define many structures, but we often hear about it within the construction domain. The parallel here extends beyond the use of the noun itself to the common fact that, as we will discuss in Chapter 5,Design versus Architecture, structure, and design, whether for software or a building, are the results of the requirements of different stakeholders.

Explaining precisely what software architecture is or does is hard. Still, luckily, an at-hand comparison that gives us some perspective on the impact of an architectural decision is building architecture. Just think about how hard it is to change the architecture of a finished construction. The same goes for software. Even if the “damage” is not as visible as it would be when tearing a house apart and building it again, the implications are the same: time, finances, and an impact on different areas and stakeholders.

Can we define software architecture?

The debate always comes down to one question: “What is software architecture?” Although it is a highly discussed and important matter, there is no definitive and generally applicable definition. While trying to shape a meaning as thoroughly as possible, I have found many interpretations and explanations, many confusing and hard to tackle, while others were simple and to the point. For me, the subject of architecture started to make sense when I started working on a project as a full-stack developer. As I had to go through different layers in the application (working from the database to the client), I had to respect the rules that this architecture imposed. Then, step by step, by becoming more curious about different technologies and approaches in other projects, I discovered that this is an exciting and essential matter that I had to explore fully. So, to gain some clarity, let’s take the first step by discussing some existing definitions and perspectives, and then we will try to shape a report.

According to Ralph Johnson, “architecture is about the important stuff. Whatever that is.” This is a very abstract definition but may be a good representation of how important the context of the project is when determining the architecture.

Another exciting perspective I found from Eoin Woods states that “software architecture is the set of design decisions that, if made incorrectly, may cause your project to be canceled.” Though radical, Eoin Woods’ definition exemplifies how important it is to always ensure we have explicit requirements when making decisions about a system’s structure.

The list of examples can go on; however, my conclusion was that many seemed pretty abstract and ambiguous for a developer, especially one in the early years of their career. From “the process of defining a structured solution that meets all of the technical and operational requirements” to “the set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both,” each of them yet again simply underline my idea that defining architecture would create constraints and possibly many debates. What if software architecture is a set of characteristics to pay attention to while expressing a direction on which we build step by step?

From my experience, the simplest way to think about software architecture, no matter the level of experience, is this:

Software architecture is a set of characteristics that combine technical and business requirements (at the project and organization levels). You will be able to define a skeleton to help you build a performant, secure, and easy-to-extend system (or application).

So, it is a structure upon which we build step by step, one component after another, creating the relationships between them. Consider that all this is being realized while considering the bigger picture of the product.

Even though we talk about components and interactions, we must be careful with the level of abstraction. We can quickly get too absorbed in the implementation details and lose our view from where we are to where we want to go within our application development map. There is a fine line between software development and software architecture. In my opinion, and from the experiences I’ve had within the teams I’ve had the chance to interact with, I can say that it is obvious when an architect is too focused on abstractions and has no idea about what is happening in the application. At the same time, I can see when a developer lacks awareness of the software architecture.

We will debate an architect’s involvement in the development process in Chapter 6, Types of Architects and Their Focus. That’s why right now, I would like us to focus a bit more on how software architecture knowledge can help us write better code.

Among all the questions we address when talking about software architecture, two can significantly help in the development process: “What are the main components the application can be divided into?” and “How do these components share responsibility?”

Understanding how the system is divided into components and how they interact brings much greater clarity to the process of defining the responsibilities of each, seeing where best practices integrate, bringing value to reduce the interdependence of different parts of the code, and easing the process of creating unit tests. At the same time, we have a huge advantage because it will become easier to identify frequently used components, create a common ground, and apply the correct patterns.

It is easier to respect best practices and choose suitable design patterns and abstractions when we understand what we are building and why certain decisions were made at the architecture level. Everything works together beautifully and we find it easier to build a quality-oriented product (a product that respects the quality attributes set at the birth of the product).

Understanding that my team needs an overview of the application’s architecture was a stepping point in reconsidering how certain pieces of the system interact. This is extremely useful, mainly when we discuss complex team organization with dedicated subteams. It’s hard to keep track of how all the components interact, define precise requirements (especially for the teams we are dependent on), and create pieces of components that fit together when there is no overview.

All in all, if the structure of the system is built the right way, we will have a successful product. If not, at some point, we will have to start over or rewrite essential parts.

When I’m referring to the base, I particularly consider two directions:

Architecture is the foundation of the application. We already discussed this; it is as though we were building a house. It has to allow you to create the walls, the roof later, and other details that you might want along the way or as trends evolve and change, but above all, it should give stability and direction for how the rest will grow at a structural level. The architecture is a system’s base and must be carefully thought through to bypass any significant design changes and code refactoring later.