Hi Ken,
Could you provide an example how type information will be stored in plain JSON
for query `g.V(1).property("test",["long":1L,"int":1,"byte":(byte)1])`?
Thanks, Valentyn
On 2026/05/30 04:29:00 Ken Hu wrote:
> I propose we change all Gremlin Language Variants (Java, Python, Go, .NET,
> JavaScript) to serialize their HTTP request bodies as plain JSON
> (application/json) instead of GraphBinary. Responses remain GraphBinary.
> This applies to the 4.x line. The recent change to make bindings/parameters
> gremlin-lang string enables this as there are no longer any complex fields,
> only scalars.
>
> This is beneficial in several ways:
>
> Lowered maintenance cost across five languages since every GLV currently
> maintains a GraphBinary request writer in addition to the reader. JSON
> serialization is built into every language's standard library. Eventually,
> dropping the request writer from the default path removes a meaningful
> chunk of per-language code that has to be kept correct and in sync.
>
> The server already accepts "application/json" requests, that's what curl,
> Postman, and third-party HTTP clients use. Today no GLV exercises that
> path, so a regression in JSON request parsing could ship undetected. Moving
> the GLVs onto JSON means the existing cross-GLV integration suite
> continuously validates the same code path external consumers depend on.
>
> A JSON request body is human-readable on the wire and in logs. Diagnosing a
> malformed request no longer requires decoding a binary buffer, and
> provider-specific extensions are easier to add and inspect. This is
> especially helpful when writing interceptors as you won't have to deal with
> the GraphBinary-serialized bytes. It's easy to inspect UTF-8 encoded bytes.
>
> Does anyone have any thoughts on this?
>
> Thanks,
> Ken
>
