Newbie question

[Cyrille-de-Brebisson]

Hello,

Sorry if this is not the right forum to ask a question...

I am asked to provide a graphQL interface to an existing C/C++ code that I have...

As far as I understand I will be receiving a graphQL querry (which is in text form?) and will need to respond to it...

Could someone please help me understand:

1. how is the graphQL query sent from client to me (http? socket? shared memory? named pipe?)

2. The query is in text form as far as I can understand. But in which format do I need to respond? is Binary Json ok? or should it be text Json? I am assuming that the resonse will be using the same communication channel as the querry.

3. The Querry is in graphQL "language". "libgraphqlparser" seems to allow to transform it into a Json text. How is this helpfull? I mean ultimately I need to interpret the graphQL querry, does it help to transform it into Json? or could I interpret the graphQL language directly?

Thanks for helping me getting started.
Cyrille

[benjie]

GraphQL itself doesn’t care about transport or serialization, however it is most commonly exposed over HTTP and we have a separate specification about how to do that here:

https://graphql.github.io/graphql-over-http/draft/

For best compatibility you should use JSON in both directions. When you say binary json I imagine you mean BSON? I don’t see that used with GraphQL generally.

This library is a parser, it takes the GraphQL query text and turns it into an abstract syntax tree (AST) which makes it much easier to process; you don’t need to turn that AST into JSON, that’s just a demonstration to aid understanding of the data you’ll be working with.

[Cyrille-de-Brebisson]

Hello,

Thanks, this helps quite a lot...

So, this lib will take a text based gralpQL request, parse it and generate a binary structure that makes it easy to deal with programmatically so that my graphQL server can handle it...

How is the response generated? it the response a Json document? or will it be a graphQL text message?

Yes, I was talking about BSON, seems that it would be way more efficient than text based Json...
I guess I am too old school and have issues understanding why text based stuff would be used when perfectly good binary options are available :-)

Cyrille

[benjie]

Given that BSON is newer than JSON, I'd say that JSON was in fact the old-school approach! But as it happens, someone took the time to compare JSON+deflate to CBOR+deflate and honestly the binary only beat text by more than 10% in 19 of the 229 sample queries, so gains are generally marginal (and it even lost in 61 of the sample queries!). I've not tested BSON, but I imagine the results would be similar. JSON has the advantage of being human readable and having parsers in pretty much every modern programming language.

How is the response generated? it the response a Json document? or will it be a graphQL text message?

Section 6 (Execution) of the spec covers how a request is executed, which builds up maps (hashes, objects, whatever you want to call them) in memory, and section 7 talks about the end resulting map; then for GraphQL-over-HTTP you simply JSON encode this resulting map and send it back to the client (typically compressed using deflate, gzip, or similar).

I don't know if there is already a GraphQL execution engine for C, but if not then building one is likely to take some time. Your best bet is probably to start by translating the reference implementation into C, and then apply any optimizations you want once that is done.

[benjie]

Out of interest, I extended the suite to cover BSON. Unsurprisingly since BSON is not optimized for size but instead for access performance (designed by Mongo to make it so scanning over lots of JSON objects for specific paths is really fast, not something we need for GraphQL), so unsurprisingly it doesn't do well in the comparison:

│ count                          │ 229    │
│ jsonString                     │ 487079 │
│ jsonDeflated                   │ 75229  │
│ bsonString                     │ 543775 │
│ bsonDeflated                   │ 90659  │
│ bsonBetterThanJson             │ 1      │
│ bsonBetterThanJsonBy10Percent  │ 0      │
│ jsonBetterThanBson             │ 223    │
│ jsonBetterThanBsonBy10Percent  │ 169    │

(Full results can be seen here: graphql/graphql-spec#432 (comment) )

[Cyrille-de-Brebisson]

Hello,

Sorry, long musing here... So I will start with the question that I originally intended to put last ...

Question, do you have C/C++ code that will open a http server and handle graphQL queries that I could use?

With regard to json/Bson
I was thinking along the same lines as I read your response...

If the issue is:
I want to create an internal representation of a an object out of BSON or Json, which is faster... Well, it does not mater much... at the end of the day the handling of the incoming datatype will be negligible...

But if your question is: I will need to do a one off extraction of some data out of an incoming thing. Then BSON is probably much better as you can directly search, fast, some stuff in it...
For example if you do one scan of the input and act on items in it... then you can scan your bson directly without even having to do a single memory allocation, nor having to go twice on any byte in memory... which is as fast as it can get..

Apparently, json predates Bson, but I was more thinking about the fact that binary storage of data for program data exchange predates textual storage...

Maybe you can educate me in this regard....

I never understood the whole "xml is so great" movement of 15 to 20 years ago...
Yes, it's human readable... But no human is going to read them, they are designed for exchange between machines... so, apart for debugging until you get things right in the program, I see no advantage there...
And the argument: "there is no format" and therefore the "what file format is accepted" seems very flimsy also as tag names and whatnot are a "format"... yes a human can read and disambiguate between (if we take a format for vector drawing for example) and and others... but the programs will not be able to understand each others...

Anyhow, besides the point :)
Thanks for the explanations, it does help...

Thanks again,
Cyrille

[benjie]

Question, do you have C/C++ code that will open a http server and handle graphQL queries that I could use?

I'm not aware of one; there are many many GraphQL implementations that can be used to build servers (JS/TS x2, Python x2, .NET x2, Java, D, Elixir x2, Erlang, Go, Haskell, OCaml, Perl, PHP, Ruby, Rust, Scala, and probably more) but I'm not aware of one in C and I don't see it listed here: https://graphql.org/community/tools-and-libraries/

I never understood the whole "xml is so great" movement of 15 to 20 years ago...

Me neither. I think many people also struggled, and it's why JSON got so popular even though XMLHTTPRequest (XHR) was originally intended for XML.

Yes, it's human readable...

I mean... barely. XML is a soup of symbols. JSON tends to be much much more straightforward. And one of the benefits of GraphQL + JSON is that the response shape that you see in the JSON matches the request shape that you detail in GraphQL, they pair well together.

When thinking about a serialization format for GraphQL what tends to matter the most is latency between issuing a request and rendering the result, and the size over the wire can impact that very significantly. The client can do a one-time transform of the result into whatever format it finds most convenient (e.g. BSON if you so desire!), that's none of GraphQL's concern. That said, GraphQL leaves you free to use whatever serialization format you want, so if you want to use GraphQL + BSON you can absolutely do that! But your clients will of course need to support it. For maximal compatibility it's generally best to implement JSON first and then add other serialization formats as you desire.

---

Good luck, it would be great to add a C server implementation to the list! If you need support whilst building one out, the Discord can be helpful: https://discord.graphql.org, and be sure to check out the reference implementation.

[Cyrille-de-Brebisson]

Hello,

Wait, wait, your response kind of made me think that I mis-understood things...

I was assuming that I would receive a graphQL request, parse it, and respond...

But it looks like I was kind of wrong... Tell me if I got it right this time:
I will first get a graphQL, let's call it "structure" that describes formats/request and the like...
And then I will receive various requests that will "fit" the structure first sent...

Thus it is interesting to have the "structure" parsed (which is a one off), and then deal with requests as the come...

Is this a better description of the system?

Thanks again for your time and have a good weekend.
Cyrille

[benjie]

That doesn’t sound quite right to me. Have a read of https://graphql.org/learn/ to get a fuller understanding but essentially: you build a GraphQL Schema on the server which describes the data and operations supported by your system, and then you accept requests against it using the GraphQL query language. Here’s an instance of GraphiQL you can use to send queries to an example GraphQL schema:

https://graphql.org/swapi-graphql/