Reliable Web Apps 2022

Just want to share my experience as a freelance software developer over the last 5 years working with different teams on B2C web applications in the cloud.

Dont write too much code

Big drivers for too much code are

DI (dependency injection)

A nice example is DI (dependency injection) for improving testability. This is only true if you do not have technologies that mock or simulate dependencies, e.g. some http client. But in all web-frameworks these technologies exist, e.g. you could use MSW (Mocked-Service-Workers).

In rare cases DI makes sense to enable an easy replacement of deeper layers, e.g. replacing the mail provider, but only use DI to enable testing of layers of your application introduces complexity that does not help the customer.

OO (object-orientation)

For sure there are benefits from it, but using inheritance and defining too much classes introduce abstraction that needs to be understood by other developers. Why should I split non-reusable routines in several classes? You need to jump around and find stuff instead of understanding the underlying problem. Hiding the problem in many small parts results in more code and less clarity.

Simplify the layers

Having a repository layer and a controller layer plus domain interfaces is enough in most cases. Sometimes you need to add some domain algorithms that can be implemented with simple POCOs - that's it.

I more often see (mainly JAVA backend REST services) where almost all classes depend on something else in any layer. Dependencies have to follow rules as:

1. The repositories return domain objects
2. The controllers access repositories to return those objects => Controllers reference repositories and domain classes => Repositories only reference domain layer => Domain objects reference nothing

What problem needs more dependencies?

Write the right tests

Sure it was enlightening 10 years ago to learn about DI and how to write unit tests, but unit tests are rare - not many units have that much logic that needs to be tested.

It is more important to know if a controller does the right thing than to have unit tests for every layer. Therefore some level of integration seems to be the right way.

There is nothing like a rock-solid definition of integration tests, there is only the idea that it is less effort and more meaningfulness if integrating stuff.

1. Write a single test covering stuff that belongs together
2. Mock stuff like Network dependencies
3. Only tests with easy-to-understand titles improve the quality

Deliver and integrate small changes

The bigger the change the higher the risk. This is true on both levels:

1. Merge changes into your main branch
2. Deploy changes into production

=> Every single small change needs to be deployed to productionn instantly, else the risk to break the production system is rising

The question is: How can this be achieved?

Automated quality gates

You cannot manually check for every side-effect a small change in the code has => All quality gates must run automatically.

• Always review code changes and ask questions
• Deny changes that do not have tests
• Every fix has at least one new test that prevents the bug from happening again
• In addition to the unit- and integration tests you need a fully integrated environment you run automated user journeys on using Cypress, Playwright or something similar

Use a checklist on every Pull Request

• What could possibly go wrong?
• Is there any test that should be added on unit or integration level

Add smoke-tests for your production environment

To be sure that your production system is up and running, add the most important user journeys as Cypress or Playwright tests and execute them avery 10 minutes against your production.

You will be able to detect errors that made it through all quality gates earlier than your customers. When the phone rings you can smile, tell them that the issue is already fixed and apologize for any inconvinience.

Watch your error logs

At least on a daily base. If something is red, discuss in the team immediatly the needed fix, do never accept recurring red flags, your sense will deaden.

Trust every developer

If a developer is aware that his changes will go to production and could jeopardize the whole product, then he will deliver high quality, he will not accept doubts if his code will run, he will be sure.

The feedback loop

If some accident happened, find the reason and address it. There is always a good idea that can be implemented to avoid the accident in the future.

Infrastructure as code

When I experienced it first I was enthusiastic about building new environments whenever I need them. In reality this one never was a point. Instead it turned out that infrastructure as code is just the best way to have a 100% accurate description about your environments. Thats it, not more and not less.