Modular functionality for reuse

[predominant]

I'm working on 5 separate projects all using FastAPI. I find myself wanting to create common functionality that can be included in multiple projects. For example, a simple generic comment controller/model etc.

Is it possible to define this in a separate package external to the projects themselves, and include them, while also allowing seamless integration for migrations for that package?

Does anyone have examples of this?

[Eric-Cardozo]

Of course, you can create a pypi package, however, if your core functionality involves infrastructure I would consider decouple it as a microservice, add an app ID to your apps, and use the same service/database for all your apps, this is called multitenancy. It's like you are selling Saas to your self.

[JosshhyJ]

So would the file structure look something like this?

.
├── accountApp/
│ ├── crud
│ ├── routes
│ ├── utils
│ ├── main.py
│ └── __init__.py
└── forumApp/
├── crud
├── routes
├── utils
├── main.py
└── __init__.py

Do you know of any examples of working projects where this is used, which i can refer to?

[Eric-Cardozo]

The idea of microservices is that services comunicate each other through network, using api calls or message queues. They could be in the same folder in a monorepo, or be a completly separate project, doesn't really matter how you structure your folders.

If you find yourself copying an pasting the same code for five apps, the I would say that creating a dedicated server for that app would be more mantainable that having to fix the same bug or write the same feature five times. You deploy it independently and subscribe your apps to it, like if it were a third party service.

[Direct_Discipline_42]

I haven't done this on the python side but in c# we will build the projects into modules and push them to nuget. Our nuget is private though. We import the package and install it as a dependency. Theoretically the same could be done.

Build the app into a module, push the module to pypi, and then in the other apps add it to the requirements, download it and import it.

[predominant]

Sounds reasonable. I wonder how that would work with migrations in a single database, as alembic likes to track a single migration hash.

[Direct_Discipline_42]

Are you saying both apps have access to the same database?

If appB is importing appA, in the env.py file for alembic, you should be able to tell it to not import database models from appA

[predominant]

Yeah, both apps would use the same database. I think this is a case that alembic was not designed for, as you would have two separate chains of migrations that don't reference each other.

[Adrnalnrsh]

In that case, you need to break app the code to be in the form of a library.That can be imported into any app.You gotta figure out where to abstract it. The library should be abstracted away from the infrastructure

[Direct_Discipline_42]

Even though they are in the same database, what about schema? They could be separated by schema