Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 08:17
    CaselIT commented #1764
  • Nov 29 19:21
    codecov[bot] commented #1781
  • Nov 29 19:19
    codecov[bot] commented #1781
  • Nov 29 18:52
    codecov[bot] commented #1780
  • Nov 29 18:50
    codecov[bot] commented #1780
  • Nov 29 18:49
    codecov[bot] commented #1780
  • Nov 29 18:49
    codecov[bot] commented #1780
  • Nov 29 18:49
    vytas7 synchronize #1780
  • Nov 29 18:46
    codecov[bot] commented #1781
  • Nov 29 18:45
    codecov[bot] commented #1781
  • Nov 29 18:44
    CaselIT review_requested #1780
  • Nov 29 18:43
    codecov[bot] commented #1781
  • Nov 29 18:43
    codecov[bot] commented #1781
  • Nov 29 18:43
    CaselIT synchronize #1781
  • Nov 29 18:43
    vytas7 edited #1737
  • Nov 29 18:42
    vytas7 milestoned #1713
  • Nov 29 18:40
    vytas7 unlabeled #1717
  • Nov 29 18:36

    vytas7 on master

    feat(media): simplify default J… (compare)

  • Nov 29 18:36
    vytas7 closed #1785
  • Nov 29 18:36
    vytas7 closed #1717
Federico Caselli
@CaselIT

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

by this I mean that if we allow users to only implement sync vs async methods it's very hard to unify the behaviour.
unless we piggy back on the ws handlers instead :)
Vytautas Liuolia
@vytas7

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?..).

Federico Caselli
@CaselIT
Note that this could be mitigated by requiring that the sync version of serialize to ve always defined
Federico Caselli
@CaselIT
So basically it would just be a docs change
Maybe that could be a solution for the 3.x series. Then we could revisit this for v4?
Vytautas Liuolia
@vytas7

I'm afraid it's not that simple as

So basically it would just be a docs change

The "stream" type of handler reads data asynchronously. How would a sync method even interact with an awaitable I/O stream?
1 reply
Vytautas Liuolia
@vytas7
All that being said, I don't think we need to be blocking a3 on any of this. The current implementation is functional as-is, even though json.dumps is not customizable in some cases (SSE, error serialization, get_param_as_json()).
Federico Caselli
@CaselIT
I think I expressed myself poorly: if we require that the handlers always have the sync version implemented, even in asgi application, then we could use the sync stream handler.
ie: the problem of the current implementation is that the sync serialize may not be implemented. if we require it at least for v3 it's no longer a problem
Mykhailo Yusko
@myusko

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?

Vytautas Liuolia
@vytas7
@myusko As Falcon, itself, is focused on the REST architectural style, we may want to tread carefully. Maybe we could start off with a docs recipe, or a 3rd party PyPi package providing that functionality?
@CaselIT I probably didn't express myself perfectly either in my response, but I think I understood you as intended.
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.
Federico Caselli
@CaselIT
But the sync version would only be used to serialize errors, sse json object and deserialize json query params.
No stream there
Vytautas Liuolia
@vytas7
Two different code bases not just because of "which color is your function", but also because the most efficient ways of interacting with the input stream are different in both cases.
WSGI exposes a read()able file-like stream, whereas ASGI favours iteration.
True that; but a 3rd party handler would not know what your use case is.
Federico Caselli
@CaselIT
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
Vytautas Liuolia
@vytas7
Maybe we could do some EAFP... and fall back to the default serializer if the sync version is not implemented?
Federico Caselli
@CaselIT
But that would mean that, eg, get_param_as_json becomes async.
Vytautas Liuolia
@vytas7

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.

In any case, I cannot say that I have one proposal to rule them all either.
Maybe @kgriffs would have some ideas :slight_smile:
Federico Caselli
@CaselIT
But im that case you probably don't what to use to serialize an object that you have. Of at worst you could just do an asyncio.run
I don't think that requiring a sync implementation for the handlers is too big of a deal. Furthermore this requirement could be relaxed to only require that the json handler has both
Mykhailo Yusko
@myusko

@vytas7 yeah, make sense.

Once I'll have to show, I'lll share with you @vytas7 @CaselIT @kgriffs

It's too late in Ukraine, see you and good night.
Vytautas Liuolia
@vytas7
Isn't it just 21:55 over there? :slight_smile:
Night @myusko
Federico Caselli
@CaselIT
I'll try and update the docs in that sense @vytas7
Vytautas Liuolia
@vytas7
I feel it might make sense to iron out principal architecture first. Maybe it's just me but I feel somewhat uneasy about those rough edges.
Federico Caselli
@CaselIT
I think that I still cannot explain my point, so updating the docs hopefully solves this.
Vytautas Liuolia
@vytas7
I do think, OTOH, it is great that you actually tried to prototype something. I doubt I would have noticed the currently discussed issue purely theoretically, not looking at the code.
Just things like docs can probably be paused a bit until we decide the how and what first.
Federico Caselli
@CaselIT
The issue is just for the json handler. Json does not support streaming decoding/serializing if I'm not mistaken, so requiring a sync implementation should not pose challenges
Vytautas Liuolia
@vytas7
Yes, that is a valid point.
However
  1. 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.
  2. That would make the framework API contract less rigid. "We only require either serialize for WSGI, and serialize_async for ASGI, unless it is meant to handle application/json, sort of, we don't know".
Federico Caselli
@CaselIT
Point 2 is not "don't know" it has a well defined case:
Parsing query params as json
Serialining errors and sse object
As for point 1 you could have two different implementations for sync vs async. Ie the async one could be fancy library and the sunc version could just use the python std json
*Sync
Vytautas Liuolia
@vytas7
That's a really interesting discussion (and no, unfortunately I don't have a silver bullet design either)... but @myusko wasn't completely wrong about time of the day :slight_smile: Time for some #dadops, maybe I'll get some fresh ideas later.
Federico Caselli
@CaselIT
Yep
Vytautas Liuolia
@vytas7
I'll try to circle back on less challenging issues later in the evening, if I don't fall :zzz:
Such as implementing your suggestion on the FAQ update PR, and finally finishing port of that ASGI tutorial.
Federico Caselli
@CaselIT
I've updated the pr in any case with the doc so see how it would look.
Vytautas Liuolia
@vytas7
(falconry/falcon#1782 is ready for review again.)
Kurt Griffiths
@kgriffs
Sorry guys for being MIA today... we have family in town for Thanksgiving here in the US and it's been hard to get a way. But I will try circle back ASAP. Hopefully we can put out a3 Monday.
Mykhailo Yusko
@myusko
@vytas7 Yeah, it was around 21:45, but my son has 3 months, and 20:00 that's already too late for me :D
Vytautas Liuolia
@vytas7
Oh, that's understood :slight_smile:
Vytautas Liuolia
@vytas7
Time goes by so fast. Soon he'll be nagging for a new Playstation or smth like that. :smiling_imp: :video_game:
vytas7 @vytas7 's source of info: own kids.
Mykhailo Yusko
@myusko
Heh, that's cool! I'm already waiting for it :) the time when we will be playing PlayStation.