
Juniper: GraphQL server library for Rust - guifortaine
https://github.com/mhallin/juniper
======
shellac
This looks nice.

> GraphQL turns the REST paradigm as it's usually implemented on its head:
> instead of providing a fixed structure of all types and relations in the
> system, GraphQL defines a schema which your users can query.

I have no idea what that means.

~~~
paulddraper
It doesn't mean anything, at least not anything correct.

REST defines media formats, and the relationships are described by hyperlinks
in the media.

GraphQL is much the same in that it has a relational schema.

The difference is that GraphQL has filter and join capabilities. Vanilla REST
is usually all-or-nothing for a resource.

~~~
derefr
The writer "meant it to mean" that, given a static REST-backend codebase,
there will essentially be a static set of message schemas that will flow over
the wire. (In "really dedicated to HTTP principles" REST, these are each
indicated with their own application/vnd.org.example.barapp.v1.foo-
message+json media type.) You could write C client with a `struct` definition
for a given message type, and said code would never break, because a message
of a given type always has that schema.

GraphQL, meanwhile, allows the user to specify the "shape" of the result they
want, by specifying what fields or associations they want to be included in
the result—but these can also be _parameterized_ , and the accessor-function
that receives the arguments is free to do anything it likes with them, instead
of just using them to _select_ an association or field to pass back. It's
effectively equivalent to the ability, in SQL, to do "SELECT
arbitrary_function(field) AS column".

There's no way to create a compile-time static type, especially on the
_backend_ , which could hold the response to an arbitrary GraphQL query. (Or,
equivalently, you can think of a GraphQL response as being a tree of widely-
product-typed fields, similar to modelling a decoded JSON object in a
statically-typed language.)

~~~
paulddraper
> There's no way to create a compile-time static type

Aren't you just saying that one GraphQL query corresponds to several REST
requests?

There is the same level of typedness between an arbitrary GraphQL query and an
arbitrary set of REST requests.

~~~
derefr
It's somewhat hard to communicate my exact thought here... in REST, a given
verb applies an operation to one resource, and a given resource has a known-
at-compile-time representation, where the schema of the returned
representation should have a domain that depends only on the referred-to
resource itself—i.e. the request path—where the client picks from that domain
using the Accept header.

A GraphQL query, meanwhile, can include parameterize associations—essentially
_function calls_ —and these calls can have _non-deterministic return types_.
I.e., you can't create a static set of types to describe the shapes a GraphQL
response might take, because there is a non-finite (push-down automata number
of states rather than FSM number of states) number of possible types to the
value that the function might spit out.

Or, to put that _another_ other way: there's no way to receive a GraphQL
response without the ability to dynamically allocate memory. You can't say "I
want a response of exactly this shape" and then stream the decoded response
into e.g. a protobuf. Because the client has no way of saying to the GraphQL
parser, "don't vary your schema here."

For GraphQL to be a proper "kind of" thing to use with HTTP, each association
in the request would have to be able to take its own Accept-header-alike
attribute, so that the client could ensure that if a response is produced, it
is of a defined shape.

~~~
paulddraper
> there's no way to receive a GraphQL response without the ability to
> dynamically allocate memory

You can allocate a fixed amount of memory for a particular GraphQL response.

You can allocate a fixed amount of memory for a particular REST resource.

You cannot allocate a fixed amount of memory for an arbitrary GraphQL query.

You cannot allocate a fixed amount of memory for an arbitrary set of REST
resources.

So...I agree with what you are saying. _At the the level of a single HTTP
request,_ there is more dynamism in GraphQL. But that's not a deep
distinction; REST just presents that dynamism at a level above a single HTTP
request.

\---

Note: it is common for people to define sets of REST requests with function
calls, but write GraphQL queries in a string. If you defined your set of REST
requests in a string and wrote your GraphQL queries with function calls, you'd
see many observations reversed.

~~~
derefr
To be clearer, what I was saying is that you can't _predict_ how much memory
you'll need to allocate for a GraphQL response _given_ the particular query
you've made, because there's no way to get the server to give you a guarantee
that all the field types are scalars or length-limited strings (or arrays of
known-typed maps whose members are all scalars or length-limited strings,
etc.)

In REST, you can, by Accept-ing only media-types that guarantee such a
condition. But there's no way to _annotate_ the "function calls" [field-
accessors-with-attributes] that appear within a GraphQL request, to force the
GraphQL backend to act in a similar way to a web server with regards to media
types of associated fields. You can't say "for this response field, I only
Accept these types", and then have the GraphQL backend realize that its
response would be unwanted and throw away its work, sending back a 406 error
instead.

------
mtgx
At least now the NSA backdoors will be safe from memory corruption bugs.

[https://arstechnica.com/security/2016/01/juniper-drops-
nsa-d...](https://arstechnica.com/security/2016/01/juniper-drops-nsa-
developed-code-following-new-backdoor-revelations/)

