This project still alive?

[gabrielloliveira]

Hi @fengsp

I found your library and it is quite interesting. I would like to know if you have plans to keep the project.
I would like to send some pull requests to the repository but I'm not sure if the project will be continued.
Thank you very much in advance.

[markdoerr]

Yes, I would also like to know, if there are plans to continue this project, @fengsp :)
Please let us know, if you have no time (which we fully understand) we might combine it with Stan's project (@gluk-w) ?
Because both approaches might be quite nice to be merged.. Thanks.

[gluk-w]

It seems to me the idea of this project is to replicate django-rest-framework's approach where you can implement CRUD for any model easily. But the idea of django-grpc is to be a thin layer that allows launching gRPC server with instant access to Django models and other benefits of the framework. So even this project could be based on django-grpc.

@markdoerr maybe you have other ideas about what can be useful for django-grpc to have?

[markdoerr]

Hi Stan (@gluk-w ), yes I think in a similar direction, django-grpc is very lean and has no further dependencies - which I like a lot, but it was clear to me, how you easily generate the model serialisations (that's why I even build a stripped-down version of django-grpc: https://gitlab.com/LARAsuite/lara-django-grpc with a cool app registration feature that plugs into the central servicer without the need to hardcode the services in one central application). Maybe a little bit about the background: I am building a large project with many many django applications (https://gitlab.com/LARAsuite) and many models with hundreds of fields/tables. Writing boiler plate code for CRUD for each of the models would be extremely tedious. That is what I like in the django-grpc-framework project: you have a proto generator that reads the models and generates to proto files and you have a very neat (django-REST-framework inspired) syntax to select, what fields in the model one would like to serialise and finally basic CRUD operations are provided by the framework without further coding. These three components are extremely convenient. If the django-grpc-framework is not supported anymore - maybe due to lack of time - I would help to implement these features into django-grpc - or do you have even a smarter idea @gluk-w , how to solve this challenge of writing CRUD interfaces for large django projects ?

[gluk-w]

@markdoerr ,

Your use case is perfectly legit. It could be a separate python package for model <=> protobuf serialization and source code generation. I'll be happy to contribute to it. But it is not needed for all use cases as gRPC is action-oriented rather than entity-oriented. So I would rather keep django-grpc doing one small thing, but doing it well.

It would be great if you contribute automatic servicer registration into django-grpc.

Happy to continue the conversation,
Stan

[AMontagu]

Hi !

I know it's not the main question of this issue but I think it can interest some people that are asking the same as you.

We are maintening in my company: https://github.com/socotecio/django-socio-grpc/. It's originally a fork from django-grpc-framework but we added all the production ready functionnality (and we use it in production).

• Automatic proto generation from services & serializers (and not models)
• Decorator system inside service to acte like custom action in DRF
• Support of async
• Authentication
• Fitering
• Pagination
• Support for library like django-filters
• Log system

The documentation is not full yet but I am working on it when I can.