How Software Development Is (Not) Different in the Front End and Back End

In the development of web services, the various tasks can be divided into front end and back end. Roughly summarized, front-end development refers to all work that primarily deals with user interfaces. The front end communicates with the back end, which is responsible for managing persistent data in a meaningful and efficient way and making it available to all consumers. In web development, the boundary between front-end and back-end thus lies between browser and server. This article lays out the similarities and differences between front-end development and back-end development.

Common Principles

Any type of development generally benefits from the following conditions:

• Clear definitions and prioritization of requirements in order to derive technical requirements, which can then be translated into code in the case of software development.
• Technical support in the form of various tools (auto-completion, linter, CI/CD, …). A wide range of such tools are available nowadays and should be part of every standard setup. The spell checker in any modern text program is a good example: Of course, it is possible to write an error-free text without it. But it is likely to catch many typographical errors, and one can add foreign words manually.
• Covering the code base as completely as possible with tests. Testing not only helps to ensure that all known use cases are run during development, but also makes further development much easier later on.

When developing a web application with JavaScript, for example, the following tools could provide technical support:

• prettier for auto-formatting
• eslint for static analysis
• Testing tools such as the Testing Library and Playwright to create end-to-end tests.

Front-End Testing

Linter and test frameworks exist for most programming languages, but test development in the front end often comes with additional obstacles, provided that the desired feature can be tested in a meaningful automated manner at all. What exactly constitutes an “intuitively usable” interface is a highly subjective assessment: i.e., the requirements and expectations of different users vary. Add to this the question of which browser, in which version, under which operating system and device with which display size is used–there are already a whole lot of unknown variables. Tools such as Playwright help enormously by running tests in different browsers automatically.

The topic of accessibility is also getting more attention, bringing new challenges and rules for development. Here, automatic tests are only partially possible and ideally a person does manual testing at regular intervals.

Back-End Expectations

I do not want to suggest that test development in the back end is generally easier or less demanding. Rather, other problems come into play here, such as the conflict-free and efficient processing of parallel requests. But it is generally easier to recreate different scenarios and have them tested automatically.

It’s also important to note that a back end is allowed to simply reject invalid input. The program is expected only to clearly state which part of the input was considered invalid. Figuring out the reason is typically the client’s task (for instance, the visitor should have pressed button X). The front end should mediate between the potentially inexperienced visitor and the back end. In the best scenario, of course, the back end receives only successful requests, the credit for this success lying primarily with the front end, which makes it possible through a good user experience (UX).

Error Handling

If unforeseen errors do occur, it is easier in most cases to track them in the back end. Typically, the external circumstances (hardware, operating system, …) can be quickly recorded or are already known.

As a last resort, a developer can interact directly with systems. Invalid entries in the back-end database can be removed manually. But if there is a problem in a visitor’s front-end (browser) storage, it’s rarely possible for a developer to gain direct access and the problem often has to be solved in other ways, for example by falling back to default values. Thus, the front end should offer some options for a non-fixable state, such as a button for resetting the local settings.

Communication

Another common difference in the development of front end and back end are the developer teams themselves. Separating the work may be due to personal preferences, thanks to the clear boundary between browser and server, a division in development tasks is quite appropriate. This principle is described generally in the computer field as Conway’s law. Accordingly, communication between the different teams is fundamental to guarantee a correct and efficient exchange between the front-end and back-end products.

On the technical level, the OpenAPI specification is a good guide to communication. Projects that build on the specification, such as Swagger UI and OpenAPI-diff, can provide structure for good documentation.

In summary, front-end and back-end development differ in enough areas to make respective specialization possible or even necessary. However, the basic recommendations and approaches for working efficiently remain largely identical. This principle also applies to other development categories, such as system programming, which involves a much closer exchange of data with the actual hardware of the system.

Source: lpi.org