Give raw string bytes in socket message instead of string

[projects2080]

Is your feature request related to a problem?

For very high performance websocket clients it is sometimes not desirable to automatically convert bytes to string, even if the server sends as string. It's unnecessary overhead when using high performance json parsing like orjson which can handle bytes faster.

Describe the solution you'd like

A flag that allows me to opt in to receiving bytes of string instead of actual python string.

Describe alternatives you've considered

Switch to synchronous websocket client (already supports this).

Related component

Client

Additional context

No response

Code of Conduct

• I agree to follow the aio-libs Code of Conduct

[bdraco]

Look at how aioshelly implements this. Let me know if you were thinking something else

[projects2080]

@bdraco sorry I can't trace through that library at the moment to understand the approach.

I was thinking in session.ws_connect have a flag (not sure what to call it, maybe str_bytes=True) and if so either give the string bytes directly with WSMsgType.TEXT (or maybe more sensible to use WSMsgType.BINARY)

[Dreamsorcerer]

Look at how aioshelly implements this. Let me know if you were thinking something else

Isn't that just relying on orjson working with str? As far as I can see, decoding to str is not optional currently:

aiohttp/aiohttp/_websocket/reader_py.py

Lines 272 to 274 in 056d929

	if opcode == OP_CODE_TEXT:
	try:
	text = payload_merged.decode("utf-8")

[bdraco]

https://github.com/home-assistant-libs/aioshelly/pull/713/files

But I just realized you care about the incoming not the outgoing

[bdraco]

I was thinking in session.ws_connect have a flag (not sure what to call it, maybe str_bytes=True) and if so either give the string bytes directly with WSMsgType.TEXT (or maybe more sensible to use WSMsgType.BINARY)

You'd probably still want WSMsgType.TEXT since it has different semantic meaning than WSMsgType.BINARY.

It gets a bit messy because WSMessageText than can be str | bytes. Maybe we end up with WSMessageEncodedText but not sure how to handle that in 3.x.

I can see why you want it though as other libraries and yes, aioshelly have the same issue with the needless decode overhead that orjson will do for you.

[Dreamsorcerer]

It gets a bit messy because WSMessageText than can be str | bytes. Maybe we end up with WSMessageEncodedText but not sure how to handle that in 3.x.

Not sure how to handle that in any version. We should know whether it's str or bytes, so we probably need 2 types and need to figure out a way for the typing information to know which of the 2 message types we should be receiving.

I suspect that'll be fairly complex to figure out.

[Dreamsorcerer]

e.g. ClientWebSocketResponse may need to become Generic depending on the parameter, so that .receive() can have 2 different unions for the return type. Same for web side.

[bdraco]

Managed to work it out. The actual change is about 7 lines.. and than another 100+ lines of typing :(

[bdraco]

Without Unpack we have to write everything for ws_connect out for both

[bdraco]

and we need Self as well to properly type it.

[bdraco]

I gave up on the typing and closed #11764. It doesn't seem like we should add hundreds of lines of typing just to support this change

[bdraco]

Another option would be to add the option to receive and a new api to receive_text_bytes