Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is GraphQL the Next Frontier for Web APIs?

brandur.org

Post reply on HN
Print view View original

21–30 of 74 posts

Re: Is GraphQL the Next Frontier for Web APIs?

#21

Post by daliwali »

brandur wrote: post #9
daliwali wrote: post #6

By Betteridge's Law of Headlines, the answer is "No". REST describes the architecture of the web, which most websites already conform to. Developers could design web APIs more like web pages, but standard media types must be adopted first. JSON-LD is a strong contender at that.

> By Betteridge's Law of Headlines, the answer is "No". I feel a little bad for phrasing a title like a question, but an alternative working title was "The Future of API Paradigms". I tried to touch on a variety of possible paths beyond GraphQL, including that REST might be the right way forward. > REST describes the architecture of the web, which most websites already conform to. Developers could design web APIs mor…

Having a specification that tells you exactly how to do a particular thing can be more expedient than being open to interpretation. But short-term benefits aren't exactly a goal of REST:

>REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release. [0]

There isn't anything about REST that is opposed to flexible querying or fetching multiple resources in one request. Isn't that what web pages do already? I've used very complicated search forms and fetched lots of related data on the same page. What makes it possible is the use of standards like query strings, x-www-urlformencoded, multipart/formdata, and HTML itself. Machine clients may just need their own media types.

[0] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

Re: Is GraphQL the Next Frontier for Web APIs?

#22

Post by daurnimator »

brandur wrote: post #3

It's probably not super popular to suggest that REST isn't the be-all and end-all when it comes to web APIs, but I'm interested in a future that lets us integrate with APIs more quickly and more safely. I'm interested to hear about what people think about the subject. (I'm the author.)

I'm a big fan of postgrest (https://github.com/begriffs/postgrest/).

It creates a RESTful HTTP API out of your existing postgres schema. It practically eliminates the need to write a CRUD backend.

Re: Is GraphQL the Next Frontier for Web APIs?

#23

Post by daxfohl »

Funny thing is GraphQL isn't a graph query language. It returns lists. I'm working on a similar concept for a project right now, but that actually queries graphs / trees. (Sorry, not open source). As I've been working on this, it's struck me as odd how much query technology is built around tables and how hard it is to fit graphs and trees into it with reasonable performance.

Re: Is GraphQL the Next Frontier for Web APIs?

#24

Post by bigmanwalter »

Exuma wrote: post #18
daxfohl wrote: post #16

REST is horrible. It encourages new developers to think in terms of CRUD, which is also horrible. ( https://msdn.microsoft.com/en-us/library/ms978509.aspx ). RPC is great. It encourages developers to think in terms of functions and leverage more creative ways of getting things done. Event Sourcing, CQRS, etc. GraphQL is really neither here nor there. It's more of a convention on top of those layers. I think it's a go…

I have a fairly dumb question. If one were building a standard web app... say, a super simple web store that lists products, allows someone to submit products and such. How would they use RPC instead of rest? Can you give some concrete examples of how it's different / better.

It's more natural to deal with collections and other data structures using RPC. REST works best with single items. As soon as you need to start generating reports, it can be complicated to create sane REST endpoints whereas it's trivial with RPC.

REST:

  GET /api/item/1
  GET /api/item/2
  POST /api/item { name: foo, collection: 1 }
  POST /api/item { name: bar, collection: 1 }
RPC:

  GET /api/items
  POST /api/items [{ name: foo, collection: 1 }, { name: bar, collection: 1 }]

Re: Is GraphQL the Next Frontier for Web APIs?

#25

Post by anon1253 »

daxfohl wrote: post #23

Funny thing is GraphQL isn't a graph query language. It returns lists. I'm working on a similar concept for a project right now, but that actually queries graphs / trees. (Sorry, not open source). As I've been working on this, it's struck me as odd how much query technology is built around tables and how hard it is to fit graphs and trees into it with reasonable performance.

Aren't you afraid you might be reinventing SPARQL ;-) ?

Re: Is GraphQL the Next Frontier for Web APIs?

#26

Post by brandur »

gbog wrote: post #14

I don't know for web external APIs but for an internal network of services talking to each other I've found GraphQL to be very convenient. The "single entry point" and "describe what you want, you'll get what you described" mindset makes it powerful, when used with the graphiql trial and error interface. We barely have to document anything anymore. It seems a bit weird to use a twisted json for the queries but it wor…

> The "single entry point" and "describe what you want, you'll get what you described" mindset makes it powerful, when used with the graphiql trial and error interface. We barely have to document anything anymore.

+1. It seems to me that another big advantage is speed of implementation. No matter how good your web stack is, implementing a whole bunch of separate HTTP endpoints tends to be fairly verbose and slow, and each should probably be tested thoroughly in separate modules. GraphQL mostly involves mapping data available in the GraphQL API to how it should be fetched in the backend. Lots of huge opportunities for sharing and reusing code, which is especially good for internal work where you don't necessarily need all the bells and whistles.

Re: Is GraphQL the Next Frontier for Web APIs?

#27

Post by throwaway2016a »

I'm a major REST advocate (spoken at conferences, written about it in books, etc) and I've been using GraphQL for a few months now and after an initial learning curve I love the flexibility.

But in my opinion, the answer is: write code once, expose both interfaces.

Here's what I mean...

I've been writing my APIs as GraphQL first. Then putting a very light wrapper around GraphQL to expose a REST interface. The REST interface is gold standard (HATEOAS, Json-API, etc) yet it is only a few lines of code. I just have a dictionary of REST -> GraphQL mappings and transform the GraphQL result to Json-API.

Then I also expose the GraphQL interface. So users that want to use GraphQL can.

It's a win-win and it didn't take me any more time to develop than just REST. As an added bonus, the GraphQL code is inherently easier to unit test by nature.

GraphQL has a lot of flaws (for one it has nothing to do with graphs -- nearest I can tell the name is only because it was first used for Facebooks graph database) and things like pagination and error handling have no standard way to do them. But it is very flexible.

Re: Is GraphQL the Next Frontier for Web APIs?

#28

Post by irq-1 »

brandur wrote: post #3

It's probably not super popular to suggest that REST isn't the be-all and end-all when it comes to web APIs, but I'm interested in a future that lets us integrate with APIs more quickly and more safely. I'm interested to hear about what people think about the subject. (I'm the author.)

Thinking about the problems with client-side SQL seems informative[0]:

* Security; allowing evaluation rather than a describing results.

* DDL; Data Structure and Types need to be learned out-of-band. Ideally we want a sort-of interactive INFORMATION_SCHEMA over http, so our tools can inform us about types/structure and we always have updated info as we write queries.

* Performance; Stored Procedures (server-side) protect against a client making poor joins; ORMs requesting too much data, etc...

* Info about Security: client side SQL doesn't know what rights it has, or you could say that a client account can't see the big picture of DDL. The understanding of rights is all communicated through non-API means.

* Info about Performance: clients don't know rate limits, current system load, what system admins consider reasonable data sizes or reasonable analytic calculations, etc...

I don't know what GraphQL does for each of those issues, but I'd love to hear.

[0] I recently setup InfluxDB which has a (private) web interface that takes raw SQL-ish, and it's so convenient.

Re: Is GraphQL the Next Frontier for Web APIs?

#29

Post by brandur »

anon1253 wrote: post #17

We tried to use GraphQL, but it in our opinion it has a major design flaw: not everything that can be expressed in JSON can be expressed in GraphQL. Since our application makes heavy use of Semantic Web (if you haven't already, checkout SPARQL and RDF which made similar promises). But this means we often end up with responses that contain URIs as map keys. This is not allowed as a filter in GraphQL, even though it is…

> I find it a particularly odd design choice to not make GraphQL spec match the JSON spec.

I can't speak for the original authors, but I can kind of understand it just by virtue of the fact that JSON is quite an ugly format that's hard to write for humans and comes with plenty of opportunity for error (missing quotes in places and the like). Their language also allows the introduction of some higher level semantics like an `Int!` to indicate that an argument can't be null.

Finally, GraphQL's query language has one major feature that makes it worth alone: you can comment things! This is something that you could never hope to do in JSON :/

Re: Is GraphQL the Next Frontier for Web APIs?

#30

Post by jkaptur »

zimablue wrote: post #8
JBReefer wrote: post #2

Nah, the next frontier is more likely everyone fully consolidating around REST as it stands today. This looks like movement for movement's sake, instead of improving developer ergonomics in an increasingly predictable world. This is like everyone finally agreed on a plug type, and someone starts to push 3 phase. Let's get all the houses wired up, instead.

I don't know enough to justify my opinion but I really really don't get REST. Having recently had to learn a lot of web stack in a short time REST was one of the most confusing parts, and I think it's because it intrinsically doesn't make sense. I have a client and a server, they need to share a language so that the client can tell the server what do do. REST seems like jumping from that situation to a situation wher…

In case you're not aware, the design you're proposing is generally called "RPC" (remote procedure call). In many ways, it's much more intuitive, but there are tradeoffs. This article might make interesting reading: http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-r....
Post reply on HN