Comments: Is GraphQL The Future?

[acjay]

I have seen the future, and it looks a lot like GraphQL. Mark my words: in 5 years, newly minted full-stack app developers won’t be debating RESTfulness anymore, because REST API design will be obsolete. By the end of this post, I hope you'll see what I see in the promise of GraphQL as a new approach to client-server interaction.

[itaditya]

@acjay great article, ...[edit by orta]

however there is one mistake in it. The article is giving the impression that rest is nothing but a network request.

Rest for static assets is good, but have problem with API

The static assets has nothing to do with REST. It's a function of HTTP. Please correct it.

Also I would like to know the pain points you're having with REST.

[orta]

Hi @itaditya - this comment doesn't really add much to the conversation, I'm quite picky about keeping our blog comments positive, constructive and on-topic. So, I'm going to have it hidden by default. You're welcome to edit it and improve it to add to the discussion 👍

[brucou]

Pretty interesting article, which generated a few comments that I submit to your consideration:

• without being an expert on graphql, thanks to your article I indeed realized that your graphql request (or script as you say) is akin to a syntax tree for a scripting language, which is interpreted by the server, An advantage by the way of that model is that you can have different interpreters analyzing the same script with different purposes (reporting, logging, etc.). Not sure that have been explored as I don' know graphQL in detail

• it seems however that that language have no proper lambda abstraction, i.e. you cannot define a function which can be reused in other parts of the script, and which would return the same value for the same inputs. That eliminates looping and recursion (no fix point operator), as you mention

• you are dead right about parallelism (expressed through vertical stacking) and sequencing (expressed through nesting)

• I was however lost in the mutation part, which is at top level of the script. Separating mutation from the query part is akin to command/query separation. However you say you can issue effectively any number of follow-up queries after your mutation completes. Does this mean that for mutation the evaluation order is reversed vs. for the queries? i.e. step1 {step2} means step1 is evaluated first and then step2? I guess this is just my lack of knowledge of graphQL showing

• This eliminates one of REST’s key weak points. Did not get that at all. An example would be good.

[acjay]

@itaditya -- your post came off to us a demanding changes, but presuming that wasn't how you intended it to be received, I want to address a couple of your points.

The static assets has nothing to do with REST. It's a function of HTTP.

I mean specifically that I think REST--as the primary design principle for accessing and managing data via HTTP--makes a lot of sense to me as a way of managing concrete resources, like static assets. It's clearly way more general than that. I'm saying that it's a great fit for documents and assets. Probably because those don't require a great deal of the subtlety of REST in its full glory.

Also I would like to know the pain points you're having with REST.

Here are some pain points with REST, in my personal experience/observation:

• Endless design bikeshedding seeking RESTfulness.
• Perpetually poor API documentation.
• Inconsistency of conventions between server frameworks.
• Inconsistency of conceptual approaches between projects.
• Tends to push a lot of complexity to API clients.

I'm not saying these are universal drawbacks, felt equally by everyone. I'm just saying I think we can do better. A better system would allow a developer to more directly work with their domain concepts and their most unique tech concerns, and spend less time on the banal parts of the machinary. Obviously, I see GraphQL as a big step in that direction.

[acjay]

@brucou Thanks for the thoughts and questions!

it seems however that that language have no proper lambda abstraction

Funny thing about this is in the course of some exploratory work on live queries, I've done some thinking about how you might get around this limitation. I no longer think this is the way to go, but it's interesting that there are ways you could immitate closures.

I was however lost in the mutation part [...]

What I mean here is that mutations in GraphQL have a return type. The most obvious return type you could chose is something that represents the result of the mutation. But that's not the only option. Your schema can specify anything you want as the return type, which could encompass the specific data changed by the mutation and/or anything else. This allows you the option to permit arbitrary follow-up queries. But this is up to you and how you want to allow your API to be used, which you determine through your schema design. In REST, follow-up operations are entirely separate requests. In my experience, this is often very tedious to orchestrate on the client-side.

In the GraphQL spec, the only fields that are mutations are the fields of the root type of the mutation operation. The root mutation fields definitely execute in series, much like in a typical programming language. If those fields return object types, the subfields are considered queries and execute in nondeterministic order. I happen to think it would have been interesting to have not made this distinction, because GraphQL already supports sequential execution, via nesting 😄.

[hpatoio]

@acjay

Here are some pain points with REST, in my personal experience/observation:

Endless design bikeshedding seeking RESTfulness.
Perpetually poor API documentation.
Inconsistency of conventions between server frameworks.
Inconsistency of conceptual approaches between projects.
Tends to push a lot of complexity to API clients.

I don't see how these issues are "fixed" in GraphQL.
Last one in particular. I think that GraphQL push even more complexity to the client.

You also forget to talk about hypermedia. I very powerful "feature" of REST API.

[wxia20]

Great writing on GraphQL I have ever read, very well explained!

[fullStackDataSolutions]

Great article. One of my favorite parts of GraphQL is that you can introspect and get the Schema in your app. This allows me to automate form creation for mutations, and to recursively traverse the schema to generate mutations and queries. If someone changes something on the back end the front end is updated just by doing an introspection, no need to write new front end code.

Because the data in GraphQL is uniform in the way it comes from in from quires, there are many things that can automated on the front end, which are not possible with REST. Such creating tables from edges and nodes.

GraphQL also greatly reduces the work the back end team needs to do to build and maintain the API. They don't need to worry about adding new routes every time the front end team needs new data, they can just expose it all in types, and if a new type is needed then expose that.

It is a very powerful tech if properly leveraged, and once developers realize what can be done with it, they will be clamoring to use it.

[leoloso]

@acjay This article is a terrific read, thanks for writing it!

Concerning GraphQL being a (meta-)scripting language, that currently doesn't completely ring true to me, because it's hidden, very hidden from the front-end developer who will code the query to access the data. Even if it uses looping/variables in its implementation in the back-end, if not directly available to the client-side, then it can't really be called a (meta-)scripting language.

Concerning this topic, I am actually working on extending GraphQL to make it apparent it is a scripting language, by giving access to programming features through the query itself, including:

• Composable fields, such as author { uppercase(name()) } or even posts { if(equals(status(), "draft"), sprintf("[Draft] %s", title()), title()) }
• Composable directives, i.e. directives modifying the behavior of other directives, which can enable looping in the query. Eg: a directive translate works well when receiving a string, as when doing title@translate(from:"en",to:"fr"), but it doesn't work when receiving an array of strings, as when doing titles@translate(from:"en",to:"fr") (unless we check for that case in the directive, which would be horrible code); however, by using <> instead of @ we can have directives within directives; then, we can loop through the items in the array, invoke the inner directive, and merge all the results, like this: titles<forEach<translate(from:"en",to:"fr")>>.

This work is in its early days, but it can already satisfy very complex queries (btw, the demonstrated final query might struck you in how explicit the control flow is).

So I do agree that the future looks like GraphQL, but I'm also certain that it will not be GraphQL, because GraphQL is actually still very limited, and so much more is possible (as I'm attempting to demonstrate). Yes, a step forward from REST, but far away from its final potential.

Btw, it's been more than 1.5 years since you wrote this article. I wonder what new insights you got since then? A follow up to this article would be wonderful 😀

[ashfurrow]

@leoloso that's really cool! Alan has moved on from Artsy, so I wanted to drop in and point to our more recent GraphQL blog posts, and I think this one about using custom directives might be of particular interest to you: https://artsy.github.io/blog/2020/01/13/graphql-custom-directives/

Take care!