Repository navigation
Replies: 2 comments 1 reply
|
This makes sense as the project grows, and separating db logic (load/save/locking) from the route handlers is a worthwhile refactor. Given main.py is still quite small right now, might be worth waiting until there's a concrete reason to split it - e.g. once the pickle->json migration (#11) or the DELETE endpoint (#8) lands, there'll be more db-side logic to justify pulling it into its own module. Splitting too early risks adding structure before there's enough code to organize. Not against it though - if others feel it's worth doing now to avoid PRs stepping on each other in main.py, that's a fair reason to do it sooner rather than later. |
|
I will process the first few PRs tomorrow. Eventually, of course, we'll need to split. I'd say right now is not the right time yet, since we're still in a super early stage. |
Uh oh!
There was an error while loading. Please reload this page.
Currently, the project keeps all of its application code in a single
main.pyfile.As the project grows, it may be worth considering splitting the code into multiple modules under a common
src/directory, and in sub-directories based on their responsibilities. For example, the SDB/database-related logic could be separated from the FastAPI routes and application setup.This could make the codebase easier to navigate, maintain, and extend as more functionality is added.
What do you think?
All reactions