serious tutorials series...with right folder structure (frontend-backend)

[abcnow]

I think it will be great to see a few video tutorials on flet showcasing how to deal with the right folder structure and restful apis for example..probably with fastapi...a tutorial that deal with frontend and backend.. from start to deployment (probably using digitalocean ..something serious --there is nothing out there yet)

I asked a few gpts plugins about the right folder structure and this is what came back:

my_flet_app/
│
├── assets/ # Contains static files like images, fonts, and CSS
│ ├── images/
│ ├── fonts/
│ └── styles/
│
├── components/ # Reusable UI components (e.g., custom buttons, cards)
│ ├── button.py
│ ├── card.py
│ └── ...
│
├── pages/ # Separate python modules for different pages/screens
│ ├── home.py
│ ├── settings.py
│ └── ...
│
├── services/ # For backend integrations, API calls
│ ├── api_service.py
│ └── ...
│
├── utils/ # Utility functions and classes
│ ├── constants.py # For constants like URLs, API keys
│ ├── helpers.py # For helper functions
│ └── ...
│
├── tests/ # Unit and integration tests
│ ├── test_home.py
│ ├── test_settings.py
│ └── ...
│
├── .env # Environment variables, not to be committed to git
├── .gitignore # Specifies intentionally untracked files to ignore
├── main.py # Entry point of the application
├── requirements.txt # Project dependencies
└── README.md # Project documentation

--- and then I went on to ask where to put the routes...

In the suggested folder structure, routes that define the navigation or URL paths within the Flet application could be organized in a few different ways depending on the complexity and size of the application. Here are a couple of approaches:

Inside the pages/ directory (for smaller applications):
If the application isn't too large or complex, you might choose to define the routes directly within the relevant page files in the pages/ directory. Each page file would not only contain the layout and logic for that page but also the route that leads to it.

In a dedicated routes/ directory (for larger, more complex applications):
For larger applications, it might be cleaner and more maintainable to have a dedicated routes/ directory. This helps in centralizing the route definitions and makes the navigation logic more modular and easier to manage. Here's how you might integrate a routes/ directory into the existing structure:

bash
Copy code
my_flet_app/
│
├── assets/
├── components/
├── pages/
├── services/
├── utils/
├── tests/
├── routes/ # Centralized route definitions
│ ├── init.py # Initializes the routes package
│ ├── home_routes.py # Routes related to the home page
│ ├── settings_routes.py # Routes related to the settings page
│ └── ...
├── .env
├── .gitignore
├── main.py
├── requirements.txt
└── README.md
In this routes/ directory, you might have a Python file for each major section of your application (e.g., home_routes.py, settings_routes.py). Each of these files would define the routes relevant to its section. You'd then import these route definitions into your main.py or a central routing file and connect them to your Flet app.

As part of a core/ or app/ directory (structuring around application core):
Another approach is to have a core/ or app/ directory that contains the main application setup, including routes, configuration, and initialization code. The structure would look something like this:

bash
Copy code
my_flet_app/
│
├── assets/
├── components/
├── pages/
├── services/
├── utils/
├── tests/
├── core/ # Core application setup and configurations
│ ├── init.py # Initializes the core package
│ ├── routes.py # Centralized route definitions
│ └── config.py # Application configuration settings
├── .env
├── .gitignore
├── main.py # Entry point of the application, initializes the core
├── requirements.txt
└── README.md
In this setup, core/routes.py (or app/routes.py if you prefer) would contain all the route definitions, and main.py would be responsible for initializing the application and tying everything together.

Each of these approaches has its advantages, and the best choice depends on the specifics of your project, such as its size, complexity, and how distinct the different parts of your application are. For most projects, having a clear, dedicated place for routes helps keep your codebase organized and maintainable.

.. when you google tutorials on flet there is almost nothing out there that takes into account production style apis (backend/frontend).. I know flet is not even in version 1.. but we are almost getting there.. and we only need a few 1 feature apis tutorials that can take all these important elements into account...

[FeodorFitsner]

Great suggestion! We are working on a tutorial for such an app.

[abcnow]

Any update on the tutorials @FeodorFitsner ? It will be great if new tutorials use the new features like adaptive page and fastapi integration.. there is nothing out there yet

[vindevoy]

Good suggestion, but I don't fully like the structure you are proposing. Sorry.

Based on what you gave, I would do it this way:

my_flet_app/
│
├── my_flet_app/
├──── assets/
├──── components/
├──── pages/
├──── routes/ # Centralized route definitions
│ ├── init.py # Initializes the routes package
│ ├── home_routes.py # Routes related to the home page
│ ├── settings_routes.py # Routes related to the settings page
│ └── ...
├──── services/
├──── utils/
├──── main.py
├── tests/
├── .env
├── .gitignore
├── requirements.txt
└── README.md

But, since we are doing this, I would rather go to MVC structure. Which is probably just a rename of some of your directories