Web-Based Application Architecture

What Makes a Great Web Application Architecture?

Every web application is a multifaceted piece of software, as in addition to the user interface, it will also include a database, background activities and many other supplementary components. In order to effectively coordinate these separate features as a single unit, developers rely on a web application architecture. This is vital to understand because when choosing a web applications development company, it could easily make the difference between the very best web app development services. At Software Planet Group, we have great experience building reliable, secure and carefully monitored architectures that dependably define the interactions between your applications, middleware and databases.

We Design and Develop Large-Scale Distributed Systems

SPG leverage the power of Agile best practices, modern tools and the experience of full-stack developers to launch large-scale distributed systems. Our expertise ranges from content delivery platforms to complex AI-powered solutions.

Monolith / SOA / Microservices

With over two decades of experience, we have witnessed all stages in the evolution of web app development, from multi-tier to service-oriented to the decoupled microservice architecture. Though we have grown to become strong advocates for the latter, we would never use it blindly, as we evaluate the pros and cons of every architecture in your company’s context.

Containers

Whether deploying to a major cloud platform or your private environment, you have the option to use containers. These often enable developers to efficiently operate at unprecedented scales. At SPG, not only does our expertise enable us to utilise containers more effectively, but we can also efficiently organise them into reliable clusters.

We use Docker and a number of Kubernetes-based services (e.g. Cloud Foundry, GKE, AWS EKS, etc.) to ensure you can scale your architecture up and down as your project requires.

Connected Apps

We understand that the needs of the modern business are rarely satisfied by a single solution. This is why we help link together a variety of different web applications to consolidate your existing ecosystem and enable effective data exchange.

Looking For a Web Development Architect?

Hire a Specialist

Our Strengths

Clock

20+ years of experience

Clipboard-list

Hundreds of projects

Shield-check

Customer Security Measures

Stamp

Compliance with international standards

Tools

Full-stack expertise

Types of Services We Offer

Pen-tool-vector

Design and Redesign

We help companies by designing their web applications from scratch or modernising their existing solutions.

Protected-file

Security Audit

Our specialists can help you to improve the security of your infrastructure through on-premise, hosted or cloud-based security audits.

Diagnostics

Performance Testing

At every stage, SPG ensure that your web application is stable and capable of handling the required workload.

We Follow the Twelve-Factor App Method

Though every web application is unique and may require a different approach to development, we have found that the Twelve-Factor App method creates a solid basis for a web application. After all, it often enables us to minimise time and cost for incoming developers, is suitable for cloud-native applications which incorporate user feedback for continuous improvement, employs declarative formats to automate setup, and keeps the application architecture scalable without compromising on practices or tooling.

Twelve Principles to Create a Solid Web Application Architecture

To build a robust web application architecture, we observe the important twelve principles below:

Git#3

1. Codebase

Code management should be carried out using a version control system like Git. Though different versions may be active in each deployment, the codebase should remain the same. This essentially means that each commit may be identified as a different deployment of the same application, a concept made more practical with Gitflow.

Ladder

2. Dependencies

While most programming languages provide a packaging system for quickly installing system-wide libraries, in our own web applications, we never rely on their implicit existence. Instead, we declare all their dependencies via a dependency declaration manifest and make use of dependency isolation tools to prevent leaks from the surrounding system. Note that this will include all application dependencies (in databases, queues, etc.), and must be managed with tools like Ansible, Chef, Puppet and others.

Terminal

3. Config

An app’s config file includes everything that is likely to vary between deployments. While some applications may store config files in the code as constants, we prefer to store config in environment variables, and thus keep these strictly separate from one another. 

4. Backing Services

Traditionally, backing services such as the database and caching systems are managed by the same administrators deploying the application’s runtime, while there may also be additional services that are administered by third-party providers. By contrast, twelve-factor apps make no distinction between local and third-party services. This allows for much greater flexibility, as for example, one of your team members could replace a local instance of Redis with an instance served by Amazon ElastiCache, and your code would not be consequently forced to change.

Send

5. Build, Release, Run

Every codebase goes through a build stage (when a code repo is converted into an executable build), a release stage (when the build is combined with the config file and made ready for immediate execution) and a run stage (when the app is run in an execution environment). By applying the twelve-factor method to our web applications, we strictly separate the build, release, and run stages. This maximises speed of delivery whilst avoiding problems like waiting on humans to restart crashed services or having to re-run the build-release-run cycle.

Git#2

6. Processes

Wherever possible, we try to execute our web applications as one or more stateless processes. This means that any data that must persist should be stored in a stateful backing service, which more often than not is a database. It also means that we should never assume that anything cached will be available for future requests. This principle allows for easy scaling and is at the heart of the microservice architecture.

USB

7. Port Binding

Though web applications are sometimes executed within web server containers like Apache Tomcat, ideally, they should be entirely self-contained. This is achieved through exporting HTTP as a service via port binding and listening in to incoming requests. As a result, our web apps are able to become a service to other web applications.

Settings

8. Concurrency

When running your code, a number of little processes handle very specific needs. You might have dozens of them to deal with web requests, and yet another dozen to handle API calls for enterprise users. This is why we take cues from the unix handling of service daemons, as it allows us to configure your applications to deal with various types of workload and means that adding more concurrency is a simple and reliable operation. Consequently, as your need for scalability increases, rather than running a single instance on the most powerful machine available, we can simply deploy more processes — or copies — of your application.

Trash

9. Disposability

Still according to the method, processes should also be disposable, which allows developers to start and stop them at a moment’s notice. This maximises robustness with shorter startup times and more graceful shutdowns, and provides much greater agility when scaling up your application’s architecture.

Stamp

10. Dev/Prod Parity

To the extent of our ability, we try to keep development, staging and production as similar as possible. The result is continuous deployment, which enables us to minimise the time, personnel and tool gaps. 

Text-width

11. Logs

Ideally, all logs should represent time-ordered, aggregated events of your running processes and be viewed by developers in their local consoles. This provides increased visibility into the behaviour of a running app and enables pushing to real-time consolidated systems for long-term archiving and data-mining such as Hadoop. While we strive to follow this principle as closely as possible, at the very least, we will capture errors and send them to error reporting services like AirBrake, Rollbar, New Relic or Splunk.

User-folder

12. Admin Processes

Finally, when it comes to admin tasks, these should be run as one-off processes. This is mostly about managing one’s application, but it is still nonetheless important. By running tasks from the relevant servers and shipping admin code alongside the app, we can isolate the application’s dependencies and avoid synchronisation issues.

Leave Your Architecture to the Web App Experts

Get In Touch With SPG Today!

Related Blog Posts