Writing a Deployable Application — Web Edition
Writing web applications is one of the most common tracks existing in the field of computer programming. The nature of web applications overall is that they are in some way available from or communicating through some form of network. They are deployed.
Deploying the applications can often result in snags. There are patterns and best-practices available to make sure deployments go smoothly. Here’s a few things to focus on.
Manage Your Dependencies
It’s almost universally true that applications depend on libraries. Whether it’s a server-side library that deals with JSON or a client-side library that provides some nice charting chances are you’re deploying code that isn’t your own.
As a developer — front or back-end — keep in mind that your dependencies come at a cost.
Security
Whether it’s the recent log4j debacle or malicious actors against npm packages, security is an issue. Know what your dependencies are, use good decision-making when choosing whether to include a new dependency, and use automated security checks like npm audit and dotnet list package --vulnerable or use one of the other options including commercial options like those provided by Snyk or open-source options like the OWASP Dependency Check.
Performance
Server-side dependencies can increase your deployment time but aside from server-side footprint typically the actual performance of a library is slightly less of a concern as libraries tend to ensure that they are reasonably performant in most cases. Advanced use-cases can surpass that “reasonably performant” requirement though so should be considered.
A slightly different twist to this is front-end performance — especially upon initial download of your web application. Keep in mind that the more dependencies you add to your front-end, the more JS, CSS, fonts, etc. are going to have to be downloaded by the user.
Maintainability
The more dependencies you have, the more you have to deal with to keep them up-to-date with security updates, bugfixes, etc. Each update has the chance for the library to improve, but also to introduce breaking changes.
Keep Your Secrets a Secret
It’s important not to check secrets into your source control. In development, use a tool that will inject your secrets outside of code that is checked into source control.
A simple option is to use a configuration override that your program will accept, but is not checked in. Each developer would manually create their override.
Another option is to use a secrets tool. For example in .Net there’s the Secrets Manager.
In your build/deployment process ensure that secrets are encrypted and the scope available to read them is limited.
Codify Your Build/Deployment
Building, optimizing, and deploying your application should be something that is codified. Doing so reduces human-error and provides documentation and consistency. A codified build/deployed can be code-reviewed and repeated in an automated manner.
As an example, many build systems such as Azure DevOps, GitHub Actions, and Travis CI now allow for steps to be specified via YAML and stored within source control. Other build systems provide build configurations using XML or JSON that can similarly be committed, diff’d, code-reviewed, etc.
Broaden Your Manual Tests
In creating web applications, it’s common knowledge that browsers are different. What works in Chrome may not work in Safari, Edge, Firefox, etc. But the browser is not the place to stop. There are 2 main categories of testing that are often missed.
Hardware
Hardware involves the CPU, memory, display, and interaction capabilities of the machine you’re running on. Typically, as developers, we’re often running on fairly beefy machines. It’s easy to overlook if our memory or CPU footprint is high if we’ve got 16GB+ of RAM and 8+ CPU cores with dedicated graphics cards and larger monitors.
It’s easy to overlook that people still use dual-core machines that only have 4GB of RAM. Test your machine on a resource-limited laptop and a budget smartphone. Test it on a 27" 4K monitor but don’t forget to test it on an 10" tablet and a 7" smartphone.
Network
We often test on localhost or perhaps a test server within our network. Step back a moment and think about what the average network a person has available to them in terms of both throughput and latency. Chrome’s dev-tools for example have a dropdown for throttling and include the ability to add custom presets that provide fields for download speed, upload speed, and network latency.
By all means, develop on your gigabit connection but don’t forget to test it throttled every now and then or on a different device or external network connection.
Accessibility
As developers, we’re not obligated (well, most of us) to be 100% perfectly accessible on each and every aspect of what we write. However, it’s considerate to keep in mind that some of our users may be differently-abled. While honestly, even scoring an “A” on most of the accessibility tests can be fairly difficult, I encourage you to try and hit at least the low-hanging fruit. It makes a difference.
