vytas7 on master
feat(media): simplify default J… (compare)
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:
BaseHandler; the ASGI variant awaits serialization, the WSGI counterpart obviously does not.
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 I/O stream?
serializemay 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?
serializeat 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.
serializefor WSGI, and
serialize_asyncfor ASGI, unless it is meant to handle
application/json, sort of, we don't know".