Do you plan to separate the DI Framework as an independent module?

[FreakinJay]

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.

[ItayTheDar]

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