3 ms·
It's not that parsing JSON to a JSON-like data structure is hard. That's easy. It's the overhead of having to parse it to a generic JSON-like data structure a
by jlokier 4y ago
It's not that parsing JSON to a JSON-like data structure is hard. That's easy.
It's the overhead of having to parse it to a generic JSON-like data structure at all, before knowing what the keys and values mean, so you can then transform the JSON-like data structure to the program's API structs.
If you knew the shape of the RPC method before parsing the JSON body, the body would be parsed directly to target language structs and variables, without using any generic key-value objects (dicts/hashes/maps), any generic arrays, or even any strings in some cases (when JSON strings represent enums). For many RPCs there would be no memory allocations during JSON body parsing. But you don't know the shape, so you either have to allocate memory and store the input in key-value objects, arrays and strings temporarily, or parse the JSON body in two passes, the first pass to get the shape for the second pass.
- pshirshov 4y ago> It's the cumbersome overhead of having to parse it to a generic JSON-like data structure at all, You don't have to do that. > If you knew the shape of the RPC method The whole idea of RPC is about "knowing the shape" (typing) and good RPC implementations do that. > you either have to allocate memory and store the input in key-value objects If I use JSON-like data structures I don't have to use classic parsers with intermediate AST representations. > or parse the JSON body in two passes I've shown you a small library which allows me not to parse anything at all.
- jlokier 4y ago> I've shown you a small library which allows me not to parse anything at all. I looked at your repo. It doesn't implement JSON-RPC or parse JSON-RPC requests, so I guess you are talking about alternatives to JSON-RPC. An RPC protocol using your library's SICK format may well be efficient (though I'm not sure it's efficient to serialise). When I saw your initial reply I thought your were saying the criticism of JSON-RPC was incorrect in the comment you were replying to. But now I realise you were saying a different protocol not using JSON can be more efficient than JSON-RPC, using a differently request format which could be used as a drop-in replacement for JSON in JSON-RPC. > If I use JSON-like data structures I don't have to use classic parsers with intermediate AST representations. Indeed, but JSON-like data structures are potentially in the "too much overhead" category by themselves, regardless of whether a classic parser is used. Parsing per se isn't necessarily the main overhead: JSON itself can be streamed as tokens. Even with your SICK format, the data structure has to be converted to target language structs, enums, etc, which is a type of parsing, even though it's not parsing text. > The whole idea of RPC is about "knowing the shape" (typing) and good RPC implementations do that. Indeed. The type of a JSON-RPC request is known only when the "method" key is read, and that key can occur anywhere in the top-level object. Start, middle or end. Finding "method" requires at minimum a pattern-matching scan of the JSON body. Until that's done there's no way to know what types the other values in the JSON body are to be mapped to in the API's target language. So we can agree good RPC implementations "know the shape" when reading a request body, and JSON-RPC doesn't have that property. (A variant of JSON-RPC which uses an array with the method in the first element does have that property though. That one has the merit of the high level of cross-language tool compatibility due to JSON, a 1:1 correspondence with JSON-RPC requests, plus the capability to serialise/parse directly from/to target API structs, variables, enums etc in whatever language without requiring any intermediate JSON-like data structure.)