At Intersys, we understand that developing a great application largely depends on creating the right type of web application architecture. If you’re a CEO, CTO, software developer, consultant, or another stakeholder creating a software product, there are countless decisions to be made from high-level project management to the nitty-gritty, in-the-weeds details that can consume a development phase. The following describes what makes a good architecture, how to make the difficult business choices, and how to decide the best technologies to use.
The foundation for an outstanding web application is its architecture. Developing the right web application architecture makes decisions much simpler and ensures future growth. It also defines the interactions between components, illustrates how services and databases are coupled together, and determines the best practices for stakeholders to follow. A proper web application architecture is:
- Agnostic (language independent)
- Automatic (automated deployments)
- Enjoyable (positive consumer and developer experience)
- Fast (quick response times)
- Modular (highly cohesive and loosely coupled)
- Secure (withstand malicious attacks, no single points of failure)
Software applications that are “automagically” updated, tested, and deployed are how startups rise, and bigger companies stay competitive.
A user goes to their browser, types in a website URL, and then hits Enter. Once the Enter key is released, a request is made from the user’s browser (client) and routed through a series of steps to the Internet-facing computer (server) that holds the content for the website being navigated. The server responds to that request by sending files back to the client to show a user interface to the user. This all happens (hopefully) in an instant.
But what happens when the production deployment of that website is taken down because continuous integration and continuous deployment techniques aren’t implemented? Or more partially, a database has to be dropped manually then re-added from backup?
So, web application architecture must be enjoyable, eh? Not exactly. What enjoyable means in this context is that both the developer and user should be first-class citizens in how the web application is created.
Developers should be given the tools necessary to quickly and efficiently create and test code. They should also have access to review other developers’ code and access to development and stage environments to ensure code builds complete successfully, tests pass, and quality is assured. This means that a developer should not have to manually kick off an entire build and wait 30 minutes to 6 hours to see if their code fix worked.
As a user, they should receive an intuitive, seamless experience. If something goes haywire, the user shouldn’t notice the blip. If errors do occur, errors should be rendered to the user in an informational and accurate manner. The user shouldn’t have to wait 3 minutes for a page to load but instead experience clicks and component loads that are fluid and fast.
The need for speed couldn’t be more accurate in this day and age. For example, the critical rendering path is an important topic because of how fast users navigate away from a website with slow loading times and no vision of progress, i.e., loading icon. The speed element starts with the server’s hardware and ends with the end of the page load barring any lapses in Internet connection.
A good web application architecture takes speed seriously. There are numerous options available to increase speeds for architecture components such as:
- Content delivery networks
- DOM reflow avoidance
- Module bundling
- On-demand asset loading
- Load balancers
- Server-side rendering
- Database indexing
- Service works
Web application architecture should have a logging service that records the following events:
- Security incidents
- Policy violations
- Unusual conditions
- Attack detection
- Business processes
- Performance issues
For an event occurrence, the service should log the information with:
- When: Date and time (international format) of log and event
- Where: Application identifier, service, geolocation, entry point URL, and code location
- Who: Machine or user – potentially user’s IP address and hashed user information if authenticated
- What: Event type, severity, and description
Optimally, an admin dashboard should be used/created to monitor these logs and their occurrences. Some examples of visual dashboard software are Splunk, Datadog, and Logstash. Logging services are also included with Google Cloud Platform (GCP) and Amazon Web Services (AWS).
The components at an architectural level include the APIs, services, web servers, databases, content delivery networks, and load balancers. When an architecture is created, modularity, as well as its close cousins–high cohesion, loose coupling, and scalability–must be accounted for.
Cohesion is the degree to which the elements of a particular module belong together. An architecture that is and has code that is functionally cohesive means that modules are grouped because they all contribute to a single well-defined task of the module.
Coupling is how much one component knows about the inner workings of another one; i.e., how much knowledge it has of the other component. When a system is highly coupled, problems are prevalent because a module in that system is harder to fix since it is so dependent on another and vice-versa. Conversely, loosely coupled systems have components that are interconnected so that they depend on each other to the least extent practically possible.
With components that are logically modularized it becomes easier to add features to those same components down the line. This makes those components scalable.
Where does the laboriousness of defining a module within a module within a module outweigh its effectiveness? The answer is in separating the functionality of documentation, code, and even teams into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired function. Depending on the level of abstraction, each module is managed by someone or something outside of it.
Security is reasonably explanatory from a conceptual perspective, but how do we ensure an entire web application architecture is secure?
Instead of a single or double tiered architecture, ensure a multi-tiered architecture is constructed to prevent single points of failure and attackers taking over an entire web application. The use of a highly available load balancer to distribute the traffic among multiple web servers helps eliminate any web servers as a single point of failure. Also, database clusters with redundancy and fault tolerance instead of a single database eliminate single points of failure.
Before initiating data transfer with other tiers, tiers should authenticate with the use of certificates or secret-key cryptography with each other. This ensures that an attacker cannot impersonate the identity of different communicating tiers or components.
HTTPS provides an end-to-end secure connection between the client application (browser) and the server. Communication via HTTPS helps protect data in transit. TLS and SSL are the two common protocols used to protect the confidentiality and integrity of the communication over HTTPS. At a high level, a server uses valid SSL certificates provided by a Certificate Authority to identify itself to a browser. The browser and server then generate a shared secret which is used to encrypt all network communications.
If HTTPS is not enabled on the application server, the traffic between the browser and server flows over a non-encrypted connection. This helps an attacker retrieve sensitive information.
Note that Google has hinted at an SEO rating drop for websites that are not using HTTPS and are already marking those sites that do not have HTTPS as “non-secure.”
In web application architecture, scalability is closely tied to modularity. That being said, scalability deserves its place because there are differing perspectives on scaling when it comes to actual hardware. There is vertically called “scaling up” and horizontally called “scaling out.”
Vertical scaling begins with one central system and adds more resources (like more RAM) to raise its capacity whereas, in horizontal scaling, the emphasis is on the distributed architecture. You can increase capacity by adding more nodes to the system. For most purposes, horizontal scaling will be easier, cheaper, and more performant.
Therefore, whether you choose to scale up or out, critical considerations for scaling are that the web application is performant, available, and reliable. The decision about how to approach scaling should be made up front. Though planning for scalability is surprisingly simple, shifting directions down the road is complicated and expensive.
Lastly in our list, simplicity is vital to web application architecture. Who wants to use or work on a highly complex app? If the points above are taken into consideration, simplicity should come fairly naturally. In addition to this, on-boarding for new developers should be relatively seamless so that they can hit the ground running and provide value to the business faster and consistently.
There are so many things to think about when constructing a web application, and sometimes it, especially with startups, goes further than the actual architecture of the application. For instance, plan out a preferred Agile methodology for project management, define career paths for those onboard-ed employees, and conduct cost analyses. The most important thing is to start with a firm foundation that scales quickly, is organized, uses up-to-date technologies with broad communities, takes the initiative in solving security holes, and is not complicated.