Repository navigation
Do you plan to separate the DI Framework as an independent module? #74
Description
Activity
- changed the title
[-]o you plan to separate the DI Framework as an independent module?[/-][+]Do you plan to separate the DI Framework as an independent module?[/+]on Aug 2, 2024 Hi @FreakinJay!
Thank you for your kind words! I'm glad you find PyNest to be a as a pythonic alternative to the Spring Framework and TypeScript’s NestJS. Your suggestion to decouple the web server component from the DI component is an excellent idea and can indeed make PyNest a standout package in the Python ecosystem.
I'm not personally familiar with Spring, but I understand the concept you're suggesting. Decoupling the DI framework from the web framework could significantly enhance the versatility and usability of PyNest. I'd love to hear more about what you have in mind for this feature.
Interestingly, I'm currently working on a feature in PyNest that aligns closely with your suggestion. Specifically, it allows for the separation of the web server component from the DI component. Here’s a brief overview of what I'm implementing:
I have a PyNest app that includes a FastAPI instance. However, one of our API routes involves fetching data from a data warehouse, which can sometimes cause Out Of Memory downtimes. To mitigate this, we decided to schedule this endpoint logic using Airflow.
To achieve this, I created a PyNest CLI application that serves Kubernetes jobs while reusing the same providers and services used in the web server. This way, we can leverage PyNest for batch processes and worker processes, ensuring consistency and efficiency across different parts of our application.
This is the PR - #73
Reacted by FreakinJayUpdate on this request: PyNest now supports non-HTTP processes while reusing its module/provider DI. The standalone worker runner
run_workers(AppModule)builds the container and runs registered workers without serving HTTP;WorkerAppFactory.create(AppModule)is available for an existing async entrypoint. See the background-worker guide. The CLI factory also builds the same container for DI-backed commands. This addresses worker/batch reuse, but the DI system has not been split into a separately packaged, web-framework-independent library. I’m leaving this issue open for that broader request.
As a server developer experienced with Spring Framework and TypeScript’s NestJS, I find pynest to be an excellent alternative. The class-based decorators in pynest can serve as an excellent DI Framework within the Python ecosystem.
Would it be possible to further develop pynest’s decorators so that, similar to Spring Framework, they can be used independently of the web framework?
I frequently run Worker Processes and Batch Processes and hope to reuse code through a DI Framework in a single codebase. It would be very beneficial if I could leverage the DI Framework in this context.