Disscussion regarding: Add Async support in django debug toolbar

Django Internals Mentorship
1

Hi everyone this is Aman Pandey and I am interested the project Add Async support in Django debug toolbar.

I have submitted few patches in Django before.

I was researching about this project and here are some things I would like to discuss.

  • First thing we would like to do is to complete the serialisation of the toolbar perhaps adding support for DBCacheStore and revamping the previous implementation

  • Secondly verification for sync views of Django channels could be done by writing tests ( I presume )
    whether in channels or in DDT.

  • third for async views support, I am wondering if we can let DDT use channels middleware to create a custom middleware that Django debug toolbar can use to process request and response life cycle?
    specially if talking about AsyncHttpConsumer

or either to support async views of Django ( priority as discussed in the PR ) by creating a new middleware for DDT

I am still looking in depth, and add further information

CC: @CodenameTim

2

Hi @salty-ivy, thanks for reaching out. @matthiask and I are definitely interested in support.

Some of these tasks are already complete, you can review the high level project outline here. The latest work is on the serializable branch. We have two PRs that have stalled out a bit that are logical next steps:

We also need to fix the CI for main to get the mysql tests to pass again, merge main down into serializable and clean up any conflicts.

We’re starting with a memory store since it’s more similar to the existing functionality and doesn’t create tables. This is largely done, but may be tweaked as further development occurs.

The tests should exist in DDT, but see Add async tests by salomvary · Pull Request #1835 · jazzband/django-debug-toolbar · GitHub and reach out to @salomvary before taking over that work.

We can make the development environment for the toolbar dependent on channels for tests and the example app, but the distributed version of the toolbar should not have a dependency on channels. Not every project that uses Django’s async capabilities uses django channels.

There are some other folks who have expressed interest in this project too. @salomvary, one of the Djangonauts from this session of Djangonaut Space and @krishsharma0413.

1 Like
3

@CodenameTim I have undergone all the related work and also added some comments on the serialize the panels PR.

I wanted to ask if we should add @salomvary add async tests to serialize branch instead rather than main or may be more specifically fetch it into your PR, that could help us test the serialization support.

cc: @salomvary

4

apart from these as a next step,

are we looking forward to tweak debug toolbar’s middleware taking inspiration from asgiref
or may be using 3rd party asgi library’s middleware to wrap around it?

what could be the next thing after serialisation is complete?

perhaps we can write out middleware with inspirational help from here

Django’s sync_and_async_middleware or class based adoption
basically main goal is to have DDT middle ware both sync and async aware inorder to deal with async calls asynchronously as Django’s middleware does.

5

Yeah, we’ll need to update the middleware to be async compatible.

That PR needs to be updated to pass tests (may require merging main into serializeable, then rebasing that PR on serializeable, fixing merge conflicts along the way)

Regarding what’s next, there’s the project that identifies a series of remaining tasks: Async compatible toolbar · GitHub

1 Like
6

thank you so much, I have understood the process and requirements, will be back with a draft proposal

7

Hi @CodenameTim here is my draft for the project

I am still looking for Django Channels specifics for compatibility if there are any and general backward compatibility for third party panels

also regarding your comment Serialize the panels by tim-schilling · Pull Request #1826 · jazzband/django-debug-toolbar · GitHub

I am trying to think this through In which way new panels can break the third party panels?

8

This is because the toolbar would expect the panels to persist their information in the store rather than in memory. If the panel doesn’t follow that pattern it won’t work. We could likely make it work with wsgi and old django apps, but newer ones would fail (as they do today).

1 Like
9

Hi, sorry for late response, but wouldn’t memory persistence in MemoryStore holds true for the third party panels as they will always subclass Panel class and sotre API usage logic resides in base Panel class via record_stats? so shouldn’t this work by default for every third party panel out of the box?

10

I have updated my proposal, and setup a branch local branch which consist rebased serialize-panel branch and working async middleware which is async-demo branch on my fork which can show case as proof of concept.

1 Like