esseswann / graphql-binary Goto Github PK

Variables should be encoded the same way arguments do with reference to InputTypes
We disallow JSON arguments as it is dangerous unoptimizable practice.
Variables should probably be stored in an flat array which indices we point to from queries.
For traffic reduction we should probably calculate actual offset on the flight, so we reach the end of the query and start reading length headers until we reach required index

We should probably add a top level byte which describes several states

• Query
• Mutation
• Fragment
• Subscription
• Query with variables
• Mutation with variables
• Subscription with variables

Some 249 more variations might apply

I wanna try it in python, but I don't want to reverse-engineer it from the code.

Could you please write a specification? And it's better to do it in Kaitai Struct (so we get a parser for the format for a lot of languages for free).

There should be an easy way to override\add new type encoding\decoding definitions

Considering that we have string encoding structure of this kind
[header, body]
and currently header is 1 byte which limits us to 255 bytes long string.
Similar to msgpack string size header should work like this:

• If first byte is 255 we read the next byte into header. Else read header as a 8-bit integer
• If second byte is 255 we read next byte into header. Else read header as a 16-bit integer
• If third byte is 255 we read next byte into header. Else read header as a 24-bit integer
• Reach max header length of 4 bytes. Read header as a 32-bit integer

Example in msgpack
Might be reasonable to directly reference msgpack implementation

There should be a containerized proxy that would automatically encode\decode data between client and actual GraphQL server using introspection
A visible problem is that some GraphQL servers limit the introspection schema to current user permissions

A custom Apollo Link using gqlb should be created for easy integration
Correspondingly a server side solution must be provided, apollo-server-express middleware maybe?

subscription-transport-ws allows passing a string in query but it won't be properly encoded, and Base64 ruins whole purpose of this lib hence adding a link to link chain might not be sufficient and rewriting the ws link is required

Currently we're not encoding and decoding the data in arrays. We should use recursive algorithms and length headers similar to String

Integers could be stored more efficiently using same technic as in header length
The only way to do the same for floats that I am aware of is using half-precision format or minifloats
Both might be explicitly configured in extended schema

There is more info on varints here https://github.com/stoklund/varint#prefixvarint