The back-end architecture for a growing and modern application in a remote collaborative team

For many beginners in application development, deployment is simply the fact of publishing its source code either by a .zip file, a pull from Github or a Github action.

This kind of approach generally works when you are in a solitary project but when you go from this stage to growth, this approach becomes difficult 😥 especially for testing, corrections and incremental progress in collaboration with your team who now often distant.

In this article, I introduce you to simple methods allowing you to better structure your project to allow collaboration with your team and thus reduce the stress of growth.

When you make your prototype, the stacks have changed over time, in the past, several stacks such as LAMP were used but currently, several approaches are used in particular:

The NoCode and some APIs
A Monolithic application
A front-end and a back-end

Any creator would love the fastest possible solution to get from idea to production, so often when we have a great new idea, we don’t take precautions to prepare for growth.

On the user side, it is important to note that currently we are moving from local users to international users who have their requirements in terms of language, time zone, other social elements (sex, gender, etc.) geopolitics(ex. Crimea, Ukraine and Russia in apps like Google Maps).

So, a few practices are useful when starting from scratch to prepare for growth.
In the following, I will talk about the management of internal growth in the project and not the factors mentioned above.

When the project grows, as a project manager, you have to recruit new people to your team. To do this, you have to go through a tiresome stage which is the onboarding of the new person: when this is not well managed, you can go from one working day to
a week for the new person to get used to the tools and procedures.

Simple documentation can do the trick if it is available to the team. Here, it is not a question of writing a lot for fear of not boring the new person or even causing him to ask a lot of questions. It should be brief and concise. The conciseness will also depend on the structure of your project: you must therefore be rigorous about the names of variables, functions, classes, end-points, etc. from the start of the project. This will save a lot of onboarding hours for new team members.

You can also use a JSON, YAML, README.md, … file to write your documentation.
To document the end-points in JSON, we can for example do:

{
“/“:{
method: “GET”,
params: {
“id” : “integer”,
“filter” : “string”
},
response: [{
“id”:”integer”,
“title”:”string”,
“body”, thong”,
“user_id”:”integer”
}],
description: “Allows to get all posts by a user”
},
“/user/add”:{
method: “POST”,
params: {
“name” : “string”,
“email”: “string|email”,
“phone number”:”string”,
“password”:”string”
},
description: “Allows to get all posts by a user”
}
}

For README.md files, here is an example for documentation:

Docs

Get all posts by a user

URL: /
Method: GET
Settings:
Reply:

Document more easily?

Yes, you can do better and even easier using Postman. Postman, this software for interacting with APIs also makes it possible to document these interactions. Organize your server calls into folders according to modules and share them with your team.

Modularize source code

The separation of the code, we often talk about it but at the beginning of the project, many architects or developers do not succeed. This is not because no one wants to do it but because it adds complexity to the software. Surely, with experience, you learn to easily separate the code and manage growth at the base.

Well, at the start of the project, I obviously recommend that you focus on your MVP, that you use the easiest approach possible.

I advise new developers and architects to find 3 or 4 important modules of the project that can be developed separately. The first module to easily find in projects is the user management module. This will allow the user module to be reused when the project pivots.

Make modules independent

First module

It is important to make sure that the modules are independent enough to better develop them separately with different developers or different teams.

The more your modules are linked, the more the communication time increases and the delays increase.

I am convinced that as a manager of

project, it is important to optimize meeting times because less communication with the team and long meetings kill the relevance of the meeting.

Other modules

Other modules should be added incrementally and should be added starting with the least dependent modules.

Here is an example of a dependency architecture between modules:

===>

And here is a development plan for these different modules:

===>

Send important metadata
When developing scalable back-ends, it is important to take into consideration meta-data that allows consistent and understandable messages to be sent back to teams and users.

Here I want to emphasize language and timezone (as well as other meta data).

For the language, it is important to return messages: error or success in the language of the user.

The time zone applies to requests/responses containing dates. In case you don’t want to handle this, then use a date format containing the timezone.

Evaluation of the development of the back-end

After the development of the back-end module, one should always keep a log of this: