Planning the Application Architecture

Imagine building a house without a blueprint. It is the same principle when building applications. We shouldn’t just jump right into the code and start building. It can work out fine for prototypes, but not for teams building larger applications. We should have some guidelines. Every company and every application is different. This is just an exercise.

Architecture Considerations

We don’t know everything up front. We could write down some key considerations and use the headlines as exercises. It doesn’t have to take that much time. We should just narrow it down and list a few keywords. We don’t need to list everything in details. That would probably be a bad idea. We should just use it as a starting point. Remember - all apps are different and has different requirements.

App Overview

What is the goal of the application? How is the client and user going to use it? What is the business benefits?

App Features

What is the main features for the application? We probably don’t know all the features yet, but we can list the first and most obvious features.

Domain Security

In some applications there can be a lot of security involved. How is the application going to communicate with the APIs? How are we going to handle login?

Domain Rules

What domain rules do you have? Which rules do we have for login?

Tests/Logging

What should we do, when an error is encountered in our front-end application? It would probably be a good idea to have unit tests, integration tests and end-to-end tests. It would also be a good idea to have logging. Should we log straight to the console? Should we integrate with a cloud option? Should we use a third party option? We probably shouldn’t do the first option.

Services/Communication

How is the data exchanged between not only the back-end and the front-end, but also between services and components in our front-end application? Which services should we use?

Data Models

We probably don’t know all the data models up front. We should maybe just use this as an exercise. What are our data models? Are we getting what we want from the API? Is it exactly what we want? In most cases it’s probably not. So we should plan for what's the most efficient way to get data passed around throughout the application.

Feature Components

How are we going to structure our components? Which components for our features can we identify already now?

Shared Functionality

Do we have some shared functionality? Are we using any third-party components? Are we able to replace those third-party components in the future? Is the shared functionality able to be reused across any other applications at work?

Other Considerations

If you are using a framework many of these considerations will come more naturally instead of inventing the wheel. You should follow the coding conventions, naming, organising, structure, how to use components and services.

We could also consider accessibility, i18n, environment, CI/CD and APIs.