Live data from Hacker News

Writing a chat application in Django 4.2 using async StreamingHttpResponse

valberg.dk

31–36 of 36 posts

Re: Writing a chat application in Django 4.2 using async StreamingHttpResponse

#31
post #5

https://github.com/sysid/sse-starlette makes token streaming so much easier in python

I’m using this for an internal ChatGPT UI clone and it’s working great.

The actual biggest pain for me has been the front end handling of it with the fetch api. But that’s likely just due my inexperience with it.

Re: Writing a chat application in Django 4.2 using async StreamingHttpResponse

#32
“ The idea is that the client "subscribes" to an HTTP endpoint, and the server can then issue data to the client as long as the connection is open.”

To those who have been around longer than me: isn’t this just long polling, that predates websocket?

Re: Writing a chat application in Django 4.2 using async StreamingHttpResponse

#34

Earlier quoted context omitted.

Look at the intended semantics [1], and then read the implementation [2]. Can you figure out if the implementation is correct? Can you infer the possible limitations of the approach at glance? Can your async library actually handle being called with multiple event loops installed? I have zero trust in this code and I have been bitten by fixes to this library that introduced deadlocks in my own code. [1] https://githu…

Doesn't look like something I'd want to have to debug in a pinch, that's for sure. Is there anything else in Python-land you would go with for the use case you have in mind? Or does pretty much all the async stuff turn on you like this, at some point or another?

If you need to buy into the async ecosystem for some special reason my recomendation is to:

- pick a mature ASGI server

- pick a framework and libraries that have been designed from the start with async in mind. Be suspicious of libraries that support sync and async APIs without clear guard rails between the too implementations

- avoid setups where you have multiple event loops in a single process.

Re: Writing a chat application in Django 4.2 using async StreamingHttpResponse

#35

Earlier quoted context omitted.

Doesn't look like something I'd want to have to debug in a pinch, that's for sure. Is there anything else in Python-land you would go with for the use case you have in mind? Or does pretty much all the async stuff turn on you like this, at some point or another?

If you need to buy into the async ecosystem for some special reason my recomendation is to: - pick a mature ASGI server - pick a framework and libraries that have been designed from the start with async in mind. Be suspicious of libraries that support sync and async APIs without clear guard rails between the too implementations - avoid setups where you have multiple event loops in a single process.

Thanks - so is there anything in the Python space that ticks those boxes, in your view?

Re: Writing a chat application in Django 4.2 using async StreamingHttpResponse

#36
post #25
post #3

Just a heads up that currently Django is not cleaning up open PostgreSQL connections when ran in ASGI mode, leading to too many open connections error: https://code.djangoproject.com/ticket/33497

Reading that bug report it looks like Django hasn't been isolated as the source of the problem? Looks like Carlton Gibson closed it until it is reproducible. Problem could be in uvicorn, psycopg2, etc

It was. Its an implementation change made in Django v4 that caused this.
Post reply on HN