Why is the choice of architecture so important when building a Web application? What are the criteria for determining whether an architecture is good or bad? This article shows you how to design a Web application architecture that supports your current needs without laying the groundwork for the future.

Why is Web application architecture important?

Web application architecture includes all software modules and components, internal and external systems, and interactions between the components that make up the application. In addition to addressing all the business requirements at the beginning of development, the architecture ensures that all non-functional requirements (such as maintainability and agility) are met.

A well-structured Web application architecture ensures that your Web application can scale to business requirements, while ensuring that all concepts are properly isolated and their dependencies are taken into account. In summary, the architecture of the application should not only ensure that it runs on a standalone system, but should also integrate well with all other software.

What does a good Web application architecture look like?

First, an architecture is a process that aggregates many events. It’s not static: otherwise you just create an architecture filled with all kinds of knowledge. For example, due to the epidemic, telecommuting will be popular from 2020. No one could have predicted the need for global lock-in and the need to ensure that all employees must have remote access to every business service. But even in less disruptive years, new businesses, new use cases, new tools, etc., will come along, and you’ll have to iterate on your core architecture.

If you know that your architecture must evolve iteratively, do you track dependencies between different parts of your application? If you have to make changes, can you articulate what changes need to be made? Can you minimize the impact?

A core benchmark for Web architecture quality is the extent to which technical debt can be avoided. Technical debt refers to the cost in time, effort, and money incurred by making a bad decision at the beginning of a project that results in rework. A good software architecture allows you to cope with the inevitable changes without incuring technical debt. So to some extent only time will tell if your architecture is smart.

What is the cost of getting things wrong?

The problem with architectural errors is primarily technical debt. Due to poor architecture, technical debt can escalate quickly: any single change can have a significant impact on many different applications, and not being aware of future changes means that new code will blow up all sorts of problems in your application, while introducing new problems as you try to fix them. A simple application can easily turn into a complex and massive monster, making change more difficult and time-consuming, and having a significant impact on business innovation and iteration.

Core principles for sound Web application architecture

In the figure below, OutSystems is the basic building block of the service you are creating in the way of the so-called core business “entities.” The goal is to centralize functionality and reuse it across the product portfolio. If you need to make a change, you can do it once and everyone can use it. So the goal of Outsystems is not a single application, but rather a combination of applications: only when a single service is reused across multiple applications does the overall platform provide significant benefits and value.

This article first send WeChat messages public number: front-end pioneer

Welcome to scan the two-dimensional code to pay attention to the public number, every day to push you fresh front-end technology articles

Read on for the other great articles in this column:

  • Deep understanding of Shadow DOM V1
  • Step-by-step tutorial on implementing virtual reality games with WebVR
  • 13 modern CSS frameworks to help you improve your development efficiency
  • Quickly start BootstrapVue
  • How does a JavaScript engine work? Everything you need to know, from the call stack to the Promise
  • WebSocket in action: real-time communication between Node and React
  • 20 interview questions about Git
  • Deep parsing of Node.js console.log
  • What exactly is Node.js?
  • Build an API server with Node.js in 30 minutes
  • A copy of the JavaScript object
  • Programmer 30 years old before the monthly salary is less than 30K, which way to go
  • 14 of the best JavaScript data visualization libraries
  • 8 top VS Code extensions for the front end
  • A complete guide to Node.js multithreading
  • Convert HTML to PDF 4 solutions and implementation
  • More articles…