
REST and GraphQL really aren't that different - tylerbuchea
https://github.com/tylerbuchea/graphqless
======
jameslk
Click bait title. They really are quite different in very significant ways and
not exactly comparable. For example GraphQL APIs allow for ad hoc querying of
multiple resources and have a typed query language. Not that RESTful APIs
can't do the same, but that's why they aren't really comparable. Interesting
wrapper nonetheless.

~~~
ako
Adhoc querying of multiple resources and REST are not incompatible, see e.g.
oData. It basically offers the same functionality as GraphQL, but also follows
all the Restfull http best practices.

You can see some oData examples here: [https://www.odata.org/getting-
started/basic-tutorial/#reques...](https://www.odata.org/getting-
started/basic-tutorial/#requestData)

~~~
napoleond
AFAIK, oData only lets you request a single entity type at a time, doesn't it?
For example, in the example you provided, would it be possible to fetch a
collection of People and Airports as part of the same request? What would that
request look like?

~~~
jmull
No, you can batch requests.

~~~
wsy
The question was not about batching, it was about join queries over more than
one resource type.

~~~
jmull
I guess I should be more clear...

batch means you can do things like combine these:

GET /serviceRoot/Airports GET /serviceRoot/People

into one request (and get the results in one response)

I believe that's what the poster was asking.

Here's a link to a different example from the OData site:
[https://www.odata.org/getting-started/advanced-
tutorial/#bat...](https://www.odata.org/getting-started/advanced-
tutorial/#batch)

You're using the word "join". I'm not sure if you meant that in a relational
sense or not. If yes, then maybe you're wondering if you can get airports with
their related people, or people with their related airports in one request
with OData. Again, the answer is yes.

~~~
wsy
Thanks for the explanation!

~~~
jmull
No problem... I realize my initial answer was pretty useless. "batch" has a
specific meaning in Odata but of course you wouldn't know that unless you
already knew Odata.

------
dragonwriter
REST and GraphQL are in orthogonal domains and mutually compatible. This would
be more obvious in the most common case for each where they are being used
over HTTP if HTTP had generic (not specific to, e.g., WebDAV) safe method that
took a request body with a representation of a query and returned a
representation of the resource satisfying the query. [0]

GraphQL is basically just a generic resource representation for queries.

[0] Like the one proposed here: [https://www.ietf.org/id/draft-snell-search-
method-01.txt](https://www.ietf.org/id/draft-snell-search-method-01.txt)

~~~
headcanon
This. GraphQL is agnostic to the application layer, whereas REST is tied to
HTTP.

For instance, we have various REST-style endpoints that execute GQL queries
directly on the backend.

~~~
RussianCow
REST is also transport-agnostic and definitely not tied to HTTP, even though
that's by far the most common way in which it's used.

------
k__
Also, for doing it the other way around (REST from a GrapQL schema) there is
Sofa

[https://news.ycombinator.com/item?id=19037379](https://news.ycombinator.com/item?id=19037379)

------
dopeboy
Except when they are. I was just implementing an endpoint that returns Reddit
like comment data (replies nested in replies) and I quickly realized you can't
pull this off in graphql because the return structure has to be predefined and
static.

Ended up implementing it in REST.

~~~
nmadden
Really? It’s called _Graph_ QL and its schema can’t describe a simple tree?

~~~
Twisol
The schema certainly can, but GraphQL queries have the valuable (in many but
not all contexts) property that the response structure mirrors the request
structure. If your request is nested no deeper than four scopes, then the
response will also be nested no deeper than four scopes.

------
hirundo
When I pitched GraphQL to the boss one of the selling points was, "and if we
ever need to in a couple of days we could add a full REST API backed by
GraphQL." But now she's addicted to playing with it in GraphiQL and gets it,
and is evangelizing it to clients. In the end it's what the clients want that
matters, and so far we're getting more disorientation from them than pushback.

It looks like we'll need to give clients more support in manipulating JSON,
conversion to tabular data and help with pagination. There's a business
opportunity for apps that help non-coders deal with GraphQL queries and
results.

------
dmitriid
> REST and GraphQL really aren't that different.

As in: absolutely different, and GraphQL breaks nearly everything that makes
REST REST.

Pretending it's not in the server-side code doesn't make it "not different".

~~~
IggleSniggle
REST is an interpreted standard for stateless transactions. How do you see
GraphQL as breaking what makes REST REST? If you had said HATEOS, _maybe_
there’s something there, but GraphQL does not fundamentally break the promises
of a REST transaction as far as I can tell.

~~~
dmitriid
Good overview here: [https://blog.goodapi.co/rest-vs-graphql-a-critical-
review-5f...](https://blog.goodapi.co/rest-vs-graphql-a-critical-
review-5f77392658e7)

Ok. It doesn't break _all_ of REST's semantics and ideas. "Only" the entirety
of 5.2.1 and and most of 5.3 in the dissertation

~~~
IggleSniggle
The author is declaring one approach to REST as the "one true way." Actually,
I think the author is correct, ie pointing to a HATEOAS style REST approach.
But the REST standard is interpreted. The article calls all of the RESTful
APIs that are fragile in one way or another "so-called-REST." I kind of agree
with that assessment of quality, but at the same time, they aren't "so-called-
REST." They are actual REST. We can all just _wish_ those were "so-called-
REST" and that there was some additional mechanism to enforce "real" REST. As
it stands, accusations of "that's not really REST" amount to being "No True
Scotsman" arguments.

------
k__
I read on Twitter that 2019 will be the year of resolver centered GraphQL
frameworks (in difference to the schema based solutions). That approach should
be more aligned with REST.

------
pighive
I haven't done much JS, but what does this mean "this.post = this.put =
this.delete = this.patch = this.query = this.mutation = this.get;" in Router
Constructor.

~~~
dentemple
The "=" operator always returns the value on the right side, and it always
processes the right side before the left side.

Therefore:

1 - this.mutation = this.get // returns this.get

2 - this.query = <return value of this.mutation = this.get, which is this.get>

3 - this.patch = <return value of this.query = this.mutation = this.get, which
is this.get>

n - and so on...

Essentially, it's setting 6 different properties all to the same value.

\---

EDIT: Here's the same concept, but in a different context...

function fibonacci(num, memo = {}) {

    
    
        if (num <= 1) return 1;
    
        if (memo[num]) return memo[num];
    
        return memo[num] = fibonacci(num - 1, memo) + fibonacci(num - 2, memo);
    

}

On the return line, the right-to-left property of "=" forces the extreme right
to be processed first. It returns the recursive call.

Then, the return value of this recursive call gets saved to "memo[num]".

Finally, the return value of "memo[num] = fibonacci(...) + fibonacci(...)",
which is still the same return value from the recursive call, gets saved to
the function return.

~~~
pighive
Thanks for taking time to put an example. I am familiar with the assignment
rule, but this is a refresher. My question was more on why it was one function
being used for all others.

~~~
dentemple
Ah, well, could be useful for someone else who looks at it.

------
headcanon
Interesting, I will agree that configuring an express server and GQL resolvers
has a similar structure, in that they're composed of "routes" and "handlers"
("types" and "resolvers").

The biggest potential use case here would be to allow the server to expose a
REST-style API as well as a GraphQL one with the same codebase - is that
supported by this package? IMO it definitely should be.

The only other reason I can think of to use this is if you are used to writing
express servers and don't want to change, which isn't a very good reason to
use yet another package. graphql-tools makes writing the server pretty dead
easy.

------
good-idea
There's a lot more to be said about a schema-based API. On the server (which
this project covers), maybe it's not as important, but it is tremendously
helpful on the front end, especially when your data has a lot of relationships
(Of course, you can do this without GraphQL). I think this is a big factor in
how libraries like Apollo were able to grow so quickly.

It's also nice that it's more standardized than a REST API - I know that if I
need to work with a GraphQL api, I can look at the schema and immediately know
how all the pieces fit together and how to get what I need.

------
shay_ker
app.get('/users', (req, res) => {

app.get('/user', (req, res) => {

app.post('/createUser', (req, res) => {

These aren't what I'd consider to be RESTful... these seem more like
traditional RPC calls.

------
SideburnsOfDoom
I'm not going to say that GraphQL is bad today, but

If it returns error messages with a 200 OK status, then it's not restful at
all (
[https://github.com/graphql/graphiql/issues/88](https://github.com/graphql/graphiql/issues/88)
)

~~~
bdcravens
Isn't that easy to do with REST as well however?

~~~
SideburnsOfDoom
An error with a 200 OK status code is pretty clearly not what you _should_ do
in REST.

~~~
bdcravens
No doubt, that's bad design. However, if you try-catch the code and return a
custom error message, many frameworks would return a 200 by default if you
don't explicitly set the status code.

------
dlai
My understanding looking at the code example is it turns a rest call into a
services layer then maps it to GraphQL.

I think this creates a bad convention of creating a service layer dependency
on express where it's not needed.

As a proof, I like the idea, but in design I don't like adding extra coupling
where it's not needed.

~~~
dlai
One thing I do see that's missing (or maybe just not documented) is the power
to specify the exact shape of the response.

One of the power of GraphQl is allowing us to specify how much or how little
of the result objects we want. For example, a Blog post on a mobile app might
just want only the short synopsis of the comments and the poster's name, while
a web view might want the whole comment.

------
JakeWilson801
Obviously a basic example with one type of entity(user) makes it look the same
but GraphQL's power is in being able to create whatever view of the data you
want from the client and also being able to traverse the data's relationships
IE User to Posts explicitly at the API consumption layer.

------
truebosko
Nice! We actually generate our GraphQL Server by leveraging what our framework
(which runs off Django Rest Framework) spits out in an OPTIONS request to a
resource. We spruced it up a bit, but allows for dynamic creation of a server
similar to this.

------
jahewson
But look at how the client consumes the APIs - it’s totally different.

Some funky abstraction over express.js server code looks similar for a trivial
use case - that’s nice. But it’s ultimately nothing like REST under the hood.

------
aboutruby
Seems like a great way to start out and experiment with a GraphQL API. It just
seems like it would miss a lot of GraphQL features.

