GSOC 2020: Django Service Hooks

Hi!

My name is Ashlah.

I’ve read about Google SummerOfCode and Django’s participation as a mentor Organization. I’ve read some of the discussion in this site and spotted that the Django Service Hooks haven’t discussed yet in here.

Quoting from Django’s “Google’s Summer of Code 2020” page:

Django has a lot tied to the HTTP lifecycle, and if you run it outside of this, you miss out on some key things - like database connections being closed properly, or logging, or some middleware. The project would be to design and implement a separate way of calling Django from a service framework - even if that framework was itself HTTP based (basically, don’t rely on Django having to run through WSGI/ASGI). Initial idea is to provide a context manager that replaces the wrapping of a request, but the project would have to include requirements-gathering and interviewing people who use Django to power microservices to work out what they want.

I still don’t really understand what this idea is about. I’ve discussed this with some of my friends and they generally clueless about this idea. Some speculation that came up is this about replacing current WSGI/ASGI implementation with “something else”, so we can use Django’s great features (quoting from the quotation: “- like database connections being closed properly, or logging, or some middleware”). But I still can’t figure it out what is the expected “something else” thing is.

So I think I’ll ask some question to help to clarify this:

  • What are the concrete use cases of this idea? I once tried to use Django’s ORM solely for managing database without any HTTP communication. Is that one of the use cases? Or perhaps what this article (using Django’s management command) describes is one of them.

  • Are there any projects that have been using Django’s with this kind of context (without WSGI/ASGI) and implemented their own context manager workaround (or any other kind of solution)?

  • Is this context manager solution is about what PEP343 defined? So someone can do something like:

    with django_context(request):
        # do something with Django
        # without tied to HTTP cycle
    

    Actually I found a StackOverflow question related to this.

  • I’m not really sure what parts of Django’s that highly tied to HTTP lifecycle. Some parts came up my mind are views (ofc, views are used to handle function right?) and middlewares (Django processed the request by passing it to a series of middleware). Would anybody here share a thoughts about it?

I know it’s kinda late for starting a fresh discussion for GSOC 2020. Even if this wouldn’t pass GSOC, I think it’s worth to start this discussion for future development (I’m willing to contribute)

Would love to hear from everyone here!

Cheers,
Ashlah