Photo by Christina @ wocintechchat.com on Unsplash
There’s a lot of decisions to make when starting a new project. Your web application architecture is among the first things to discuss. Should you innovate, follow the latest trends, or stick with a proven web app architecture pattern?
Before briefing with developers, read our web app architecture cheatsheet. It will help you talk the same language with your development team and lay a good foundation for your web app success.
What is application architecture?
Architecture is usually defined as a fundamental organization of the web application. It describes the high-level internal structure of the software system and outlines the ways major parts of it are wired together.
Why is architecture important?
Web application architecture represents a set of decisions that need to be made early in a project. Those initial choices usually have far-reaching implications in all aspects of the app development process.
- Allocation of financial resources: the cost of web app development and maintenance.
- Hiring decisions: the number of people on the team and their roles.
- Work breakdown structure: a hierarchy of tasks for the team to do.
- Time to market: the absence of delays caused by changes at later stages.
- Future product qualities: performance, fault tolerance, scalability, and reliability.
- Ease of maintenance: fixing bugs, replacing or adding new functionality.
An ideal architecture that could ensure every aspect of a web app is rocking doesn’t exist. Every particular case has its requirements and prerequisites. Choosing a web app architecture often requires making the right tradeoffs depending on business goals and priorities.
Web application architecture best practices
If you get to coding without having architecture designed first, you risk ending up with spaghetti code. Your web application structure may look like a labyrinth of unmanageable dependencies between different components, layers, and tiers.
Another mistake to avoid is following trends or copying successful companies’ approaches without critical thinking. Instead, all architectural decisions should be made with the actual architectural drivers in mind. Those are a set of requirements that have significant influence over the future architecture of your web application, such as:
- Technical constraints. Some given technical must-dos should be fixed in the beginning and are difficult or even impossible to change later.
- Business constraints. Things like a specific delivery date or a limited budget narrow the range of implementable web app architecture designs.
- Quality attributes. Specific criteria that help to define if the software performs well.
- High-level functional requirements. An overview of what the web app is expected to do helps to define the core features that should be developed.
A business owner and their software development team should have several sessions to plan and agree on an optimal architecture design for the given context. Here are some best practices to follow during this process:
- Formulate the problem the software should solve for the business or its customers.
- Agree on the technical requirements and quality attributes that will define success.
- Choose architectural tactics and patterns for achieving the desired results.
- Brainstorm and suggest several options of well-suited technical solutions.
- Whiteboard a high-level web app architecture with key stakeholders.
- Document and diagram your web app architecture in detail.
- Collect feedback, incorporate it, and finalize the documentation.
To convey the idea to all parties concerned, you’ll have to build a web application architecture diagram. Such diagrams help to visualize internal dependencies between different parts of the software.
The picture illustrates the traditional high-level architecture diagram for web applications with client-server architecture that have their logic separated into layers.
Web app architecture layers and tiers
Depending on the complexity, a web app code can be kept in one or multiple projects or layers. If an app is single-purpose and simple, it can be developed and deployed as one monolith containing the entire app logic. However, in the majority of cases, apps require isolating parts of their logic in separate layers. Such separation of concerns allows developers to:
- Keep the code base organized when it continues growing
- Determine which part of code implements a certain functionality
- Standardize and reuse parts of code avoiding redundancy
- Encapsulate code within layers for better control over dependencies
- Update parts of functionality with minimal impact on the entire app
- Swap out implementations for testing or scaling purposes
Separating app code into layers widens the range of app infrastructure options. All layers can be deployed together on one server (one-tier architecture) or distributed across different servers or platforms (N-tier architecture).
Three-layer architecture in a web app
Traditionally web app logic is structured in three layers: presentation, business, and persistence. Let’s consider what each layer is responsible for, what technologies they involve, and how they interact with each other.
Presentation layer (UI) represents the frontend of the application. It includes static content and dynamic interface elements that are displayed to users.
Business logic or application layer (BLL) is part of the application backend that contains the most important logic of the app and defines internal flows for requests and data.
- Environment: Servers or IaaS, PaaS, or Serverless cloud platforms
- Programming languages: Java, Python, PHP, JavaScript, Ruby
- Backend frameworks: Spring, Django, Laravel, Express, Ruby on Rails
Persistence or data access layer (DAL) is part of the application backend that includes databases and database management systems (DBM) responsible for collecting, managing, and storing information.
Users of the app interact with the presentation layer. It sends requests to the business logic layer, which processes them. To process requests BLL communicates with the persistence layer to retrieve all required data and sends its response back to the presentation layer.
Trends in modern web application architecture
The InfoQ e-magazine has published a report on the lasting and rising trends in web development architecture. The following graph illustrates the current state of adoption of modern software architecture concepts in the industry.
Let's look at a couple of major transformations happening in web app development that have already significantly changed the common approach to web app architecture.
A shift from monolithic to service-oriented architecture
The need for greater agility and scalability makes developers move from monolithic to distributed systems. Programmers now strive to split apps into small independent units (microservices) to be able to update and scale each one of them separately.
Building an effective service-oriented or microservice architecture requires following several common principles formulated by Thomas Erl in his book SOA: Principles of Service Design:
- Standardized service contract. Make all services follow a standardized description.
- Loose coupling. Minimize dependencies between services.
- Service abstraction. Hide internal logic and details about how services work.
- Service reusability. Structure services by the don't repeat yourself (DRY) principle.
- Service autonomy. Let services internally control their own logic.
- Service statelessness. Let services not persist state from previous requests.
- Service discoverability. Provide services with discoverable metadata.
- Service composability. Ensure services can be used together.
The trend of microservice architecture is growing thanks to the availability of microservice-friendly cloud infrastructure solutions provided by AWS, Google Cloud, Microsoft Azure, and others.
The dominance of single-page over multi-page web apps
The traditional multi-page architecture used since the beginning of the web is no longer in favor. The high expectations people have towards modern web apps in terms of user experience made dynamic single-page apps (SPAs) a new normal.
In SPAs, logic is moved from the webserver to the client. As a result, SPAs please users with dynamic interfaces that don't require them to wait for a webpage to update after every click. Instead, SPAs run JavaScript on the page to render new content in response to users’ actions. To deliver a flawless user experience SPAs leverage the following architectural patterns:
- Server-side rendering. The server fetches an HTML page and passes it to the browser for display.
- Client-side rendering. The server sends the raw data to the browser where it is fetched dynamically by JS scripts.
- A mixture of both. SSR is used only for the initial page load or a bunch of URLs that deliver app views that are rich in static content (marketing pages, blog).
SPA architecture is no longer limited to small projects. Large web platforms follow the SPA trend and transform their monolith multi-page apps into sets of small interconnected SPAs. Amazon, Netflix, or Airbnb constitute an example of how complex and at the same time efficient modern web application architectures can be.
Need to build a robust and scalable web app?
To build a web application, you can start with an experienced freelance developer who will help you architect your project. If you’re looking for cost-effective options, consider hiring a senior-level programmer on Proxify.io. Hourly rates on our talent matching network start at 31,90€ / h. Just send us a talent request and get the work on your project started within two weeks.
