Cross-platform app project structure in Python

Question

I want to create a cross-platform app. It will probably be a mobile app first (maybe a web app later). For backend, I am using fastAPI (Python framework) and PostgreSQL. For frontend I would like to use React Native or Flutter. I think that the best way to structure this project will be MVC architecture.

I am implementing such an application for the first time and I would like to choose the architecture accordingly in order to have a structured design. And here is a question. I cannot find a good example of what a directory tree (project structure) should look like in such an app.

Should I split the frontend and backend into separate repositories or do it in one repo?

Could you please give me some examples of how to structure such an app? What else should I be aware of before setting up this architecture?

Answer 1

1. How fast can you expect your application code base to grow? It seems to me that this is the main criterion you should use when deciding whether to separate the front end and back end into two repositories, because if your application will be small for a long time (months), it would be impractical to have to incur the effort of maintaining two repositories. Another criterion typically used to decide this is how many people will work on the application (which in turn is a criterion directly related to the previous one): in large applications you usually have one team for the front end and another for the back end, and each team works in its own repository, since in such cases having the front end and the back end in the same repository would imply problems such as a very large folder tree, greater difficulty in documenting the repository, easy overwhelm of new developers, etc.

2. On how to structure your application: if you decided to create a single repository for the front end and the back end, you can simply structure your application this way:

.
├── front_end
│   ├── README.md
│   └── ...
├── back_end
│   ├── README.md
│   └── ...
├── README.md
└── ...

Note: notice that I put several README.md, and this is because you should have at least one piece of general documentation for the whole project and one for each part of the application (front end and back end). Each README.md should describe things like: how to set up a development environment, practices and conventions, how to do a production deployment, etc.

3. On how to structure the back end (FastAPI): this again depends a lot on how extensive you could expect your API to be. If your API will be small or medium in size (between 10 and 50 endpoints, to say something), you can use this structure (which is extensible):

.
├── __init__.py
├── main.py
├── core
│   ├── models
│   │   ├── database.py
│   │   └── __init__.py
│   ├── schemas
│   │   ├── __init__.py
│   │   └── schema.py
│   └── settings.py
├── tests
│   ├── __init__.py
│   └── v1
│       ├── __init__.py
│       └── test_v1.py
└── v1
    ├── api.py
    ├── endpoints
    │   ├── endpoint.py
    │   └── __init__.py
    └── __init__.py 

Check out this answer to learn what each file does.

Finally, if your API is going to be big, FastAPI has an official guide on how to structure a big API.

In conclusion, when architecting an application, it's always good to look for simplicity and practicality, but it's also good to make an investment in what might happen in the future. For example, architecting an application with the idea that it will be big might not be simple or practical at early stages, but in the long run it will avoid the stress of having to significantly refactor the application when it grows later.