Skip to content
Siftware Apps, and the servers they run on
■ Guide

Best practices guide to managing a web application

Everything you need to know to manage an existing web application, from supply chain to support and maintenance.

Published ·

Everything you need to know to manage an existing web application, from supply chain to maintenance.

Lesson 1: The business behind the app

Web applications are designed to achieve business goals, which means they may be tightly coupled with other parts of the organisation. For example, the application may have users across sales, finance, and logistics departments, and interface with various third-party systems, such as payment processors.

It's important to understand all of the stakeholders involved in an application before diving into development.

Start keeping records

Most web applications rely on many third parties to operate, including hosting services, DNS providers, SSL providers, domain name registrars, and a variety of contractors.

These supplier contracts may be scattered across many individuals or departments. For example, the domain name may have been setup decades ago by a founder or acquired by a legal department. You may not have any idea who's paying for the domain, when it expires, or whose contact details are listed.

Start by recording the important details:

  • What payment method is attached to each account?
  • Is the organisation listed as the owner of the account?
  • Is the contact information up-to-date?
  • When is the next renewal and/or expiration date?
  • What costs are associated with the account?
  • Who do you call if something goes wrong?

Next, set up a password management, digital wallet, or business vault solution to securely manage the accounts in a centralised location. In addition to storing credentials, they can ensure that everyone uses secure passwords.

Finally, put a process in place for adding new accounts and managing existing accounts. There should be more than one person responsible for these tasks and documented procedures in place to ensure that the business can continue operating if someone leaves. Never rely on a single person.

Ensure legal protection

Many web applications begin as small projects. Early developers may host the code on their own servers, freelancers may not be bound by contracts, and there may be very little attention paid to privacy policies, terms of service, GDPR, or other regulations that could introduce legal liability.

Start with some basic legal protections:

  • Create contracts for all of your designers and developers. At a minimum, these contracts should include a confidentiality agreement and an IP assignment agreement.
  • Create a privacy policy to comply with The Data Protection Act, or DPA, in the UK or various international privacy laws.
  • Create a terms of service agreement that users must agree to before using the application.

If you're not familiar with these matters, it's important to consult a legal professional that can help provide advice or create contracts.

Lesson 2: Infrastructure supporting the app

Web applications used to consist of little more than a single server with an HTTP server and a database. These days, a "web application" may actually consist of multiple applications spread across multiple servers. Third-party services may also be used to provide key functionality.

Model the architecture

Architecture diagrams are a great way to visualise how these different components work together and better understand a web application. If something goes wrong, you can refer to the diagram to pinpoint the problem and quickly respond.

Web applications can use several different server architectures from a hardware standpoint:

  • Single server, single database: You have a single server that contains the application and the database.
  • Multiple servers, single database: You have multiple application servers, such as a core application server and a caching server, but a single database server.
  • Multiple servers, multiple databases: You have multiple application and database servers, where the database servers might be redundant or of a different type.
  • Serverless: You use a cloud-based platform-as-a-service (PaaS) solution that is server-agnostic.

It's important to create architecture diagrams to better understand how all of these components work together.

Make the code portable

A common issue with legacy applications is that the application code is highly coupled with the infrastructure. In other words, it could be difficult to move when your infrastructure changes.

Decoupling application code from the infrastructure is a great way to solve these problems to make testing, development, and DevOps a lot easier and more streamlined.

You can do this in several steps:

  • Move all configuration variables from the application code to environmental variables.
  • Design platform agnostic service models for multi-tier applications.
  • Create a virtualised image of the server environment using a tool such as Docker or Vagrant that can be replicated anywhere.
  • Implement deployment processes with plug-and-play architecture.

We believe that portability is so important that it's one of the first steps that we take when working with new clients.

Lesson 3: Software powering the app

A single web application is actually a combination of hundreds, if not thousands, of different applications working together to provide a single user experience. It's important to understand each of these applications in detail to avoid security issues, maximise performance, and ensure a smooth transition.

Languages and frameworks

It's important to understand the languages that an application is written in for several reasons:

  • It influences human resources management since developers should have experience with the language.
  • Languages and frameworks need to be kept up-to-date for security and performance reasons.
  • Frameworks make it easier to get up-to-speed with an application since you can quickly understand how the code is organised on a high level.

Third-party dependencies

Most web applications have many third-party dependencies. After all, nobody wants to rewrite basic functionality that has already been written by someone else.

The downside is that third-party dependencies introduce potential risks and costs. If the person maintaining an open source project decides to call it quits, you may be forced to take over the project or find a new solution to avoid any security risks.

It's important to document all third-party dependencies and collect at least the following information:

  • The name of the open source project or commercial entity that's maintaining the dependency.
  • What parts of the application rely on the dependency?
  • The status of the dependency if it's an open source project (e.g. actively maintained, inactive, or deprecated).
  • Any costs associated with the dependencies.

Security risks

Web application security is becoming increasingly important as attacks become more sophisticated and frequent. Unfortunately, there are many different ways that an application can be compromised, from denial-of-service (DDOS) attacks that limit availability to SQL-injections that compromise databases.

After taking over a web application, it's important to immediately conduct a security audit. In fact, that's one of the first things that we do when taking on a new client.

Lesson 4: Managing the app workflow

A good development workflow avoids problems like overwritten files and lost work, and enables you to enforce best practices, fight regressions, and release new versions with minimal effort and stress.

Create documentation

The first step in managing development workflow is creating some documentation. That way, new developers can quickly get up to speed without having to read source code.

There are a few basic elements to include:

  • Code organisation: where different parts of the application can be found.
  • Database models: all of the database models within an application and their relationships.
  • API documentation: show how the user interacts with these data models.
  • Style guide: how code should be written to be clear, concise, and standardised.

Use source control

As a general rule, the master branch of a Git repository should always be in a working and deployable state. Any changes to the master branch should be submitted via pull requests in separate branches. This code should be reviewed and tested before being merged into the master branch and deployed.

Continuous integration

Continuous integration (CI) is a development practice whereby developers integrate code into your source control repository several times per day. Each time they 'check in' their code it is verified by an automated build that enables teams to immediately detect and track down problems before they reach production.

Benefits include:

  • Deployments are small and easy to roll back.
  • Issues are caught early before they hit production.
  • There's less time debugging and more time building features.
  • You can be a lot more confident about deployments.

Lesson 5: Handling ongoing app maintenance

Web application development doesn't stop after the initial launch. They're constantly growing and evolving over time with new features designed to meet changing business needs. At the same time, they must be properly maintained to ensure that they're secure, stable, and up to date.

What is application maintenance?

Maintenance is essential work that needs to be done to ensure that an application remains productive and cost-effective to operate.

Some examples include:

  • Technology and platform changes: Third-party dependencies need to be periodically updated to remain secure and performing optimally.
  • Scaling up resources: Web applications may require more resources as they grow over time.
  • Bug fixes: Web applications will inevitably experience bugs over time, even if there aren't any new upgrades.

Consider outsourcing maintenance

The biggest problem with maintenance is that it's not enjoyable for developers, so it often gets pushed to the back burner. Even worse, taking developers off of feature development can set back your development timeline.

Outsourcing maintenance helps avoid these issues. By having a third-party team, your developers can focus on feature development and meeting their existing application milestones.

Lesson 6: How to conduct a complete audit of your web app

In circumstances where you've inherited a legacy web application with little documentation, a web application audit is a great way to get up-to-speed and start being proactive about managing the application moving forward.

Map out the app

The first step is gaining a complete understanding of the application and all of its components. Some important questions to ask include:

  • What programming language(s) are used?
  • What framework(s) are used?
  • Is the test coverage up-to-date?
  • What server(s) exist? Are they local or cloud-based?
  • What third-party dependencies exist?
  • What database models exist? How are they related?
  • What is the application's API?

Security audit

Common audits include:

  • Input filtering analysis
  • SQL injection testing
  • Dirty data analysis
  • Cross site scripting
  • Request forgeries
  • DDOS attacks
  • Header injection
  • Script security analysis
  • Session security
  • Shell execution security
  • Outdated third-party dependencies
  • Credentials stored in code repos

Performance audit

Common audits include:

  • Caching activities
  • N+1 queries or loops
  • Database access issues
  • Load balancing
  • Memory usage per request
  • CPU usage per request
  • Concurrency issues

Lesson 7: How to outsource support and maintenance

Web application support and maintenance are two of the most neglected parts of the development process. While everyone is excited to work on new features or the latest framework, very few developers enjoy reading through legacy code, updating framework versions, or debugging an antique.

Start with an audit

We start by performing a PHP application code and security audit to ensure that your web application is working optimally and securely. Our audit covers many different areas, including code structure, server issues, database access, development workflows, email, and optimisation.

Code portability

The next step is making the web application more portable by creating provisioning scripts and build scripts, as well as setting up version control and a place to store feature requests.

There are many benefits to a portable application:

  • The application can easily move between servers, making it more scalable and easier to switch providers.
  • Multiple developers can work on the application at the same time without overwriting each other's code.
  • You aren't tied to a single service provider or developer.

Ongoing support and maintenance

We provide peace of mind and practical assistance with a team of PHP experts on hand to address any issues that arise. In many ways, it's an insurance policy against problems that might occur with applications that aren't well understood by the organisation: your lights will always stay on.

In summary

Managing a web application can be intimidating and complex, especially if the original creators are no longer active in the project. By understanding the fundamentals and conducting a complete audit, you can quickly gain an understanding of how everything fits together, discover potential security and performance risks, and create a workflow for maintaining the application over the long-term.