In an unrelated note, @CaselIT , sorry to be the party pooper, but I still have some conceptual questions wrt falconry/falcon#1768 (and I even don't know what the best solution is :grimacing: ).
I don't think this is solvable with the current design
I need to crystallize that mess of random thoughts that were circulating in my head and write something concrete...
I was basically thinking that we would have two types of handlers:
- Stream handlers, much like the current
BaseHandler; the ASGI variant awaits serialization, the WSGI counterpart obviously does not. - Binary data handlers, not dissimilar to the current
BinaryBaseHandlerWS. Always sync.
The latter would handle WebSocket media, SSE, and error serialization. Error serialization probably being the most questionable one whether it is enough.
However, in case more complex logic is needed, one could override the awaitable custom error serializer (is it awaitable now?..).
awaitable I/O stream?
1 reply
serialize may not be implemented. if we require it at least for v3 it's no longer a problem
how does it work? don't you need an actual graphql library that you handle control to? in that sense there is not much for falcon to do, other than to pass along the query and return the results
Under the hood, it requires using the https://graphene-python.org/ library, from my point of view, it will be really nice to have in falcon out of the box.
In my free time, I'll try to play with it, and implement in Falcon itself, what do you think guys, make sense?
What I'm trying to say is that requiring the sync
serialize at all times is not that trivial as it sounds. As soon as your handler is actually streaming data (as opposed to reading a binary string in one pass), that may require two different code bases. I'm not just speculating, but can attest that myself too, sweating and swearing, having written those multipart handlers.
I don't think they need to. They just need to implement the sync interface of the handler. I really can't see what would be the problem.
Say that you have implemented an async handler operating on an asynchronous chunk iterator. There are many async libraries cropping up nowadays that operate in this mode. "Sans IO" as they say.
Maybe @kgriffs would have some ideas :slight_smile:
However
- You can only make this assumption about a general purpose JSON library. Theoretically, there might exist JSON implementations that take advantage of streaming. For instance, I think it's not uncommon for those fast parsers to cache identical items in order to conserve memory, and at times even speed up parsing.
- That would make the framework API contract less rigid. "We only require either
serializefor WSGI, andserialize_asyncfor ASGI, unless it is meant to handleapplication/json, sort of, we don't know".
Serialining errors and sse object
*Sync
