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

31–40 of 74 posts

Re: Is GraphQL the Next Frontier for Web APIs?

#31

Post by anon1253 »

brandur wrote: post #29
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 l…

Oh I totally agree there. I never quite grokked the obsession with JSON these days. But if you go to trouble of writing a query language that /specifically/ targets JSON output ... it seems like it would at least need to be comprehensive. Or come up with another output serializer/deserializer ... but that would put considerable strain on the consumers.

Re: Is GraphQL the Next Frontier for Web APIs?

#32

Post by brandur »

throwaway2016a wrote: post #27

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 in…

> 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.

It's good to hear that there are some REST people that are open to potential alternatives :)

> 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.

I'd certainly agree there. This could change in a year or two, but right now REST-ish APIs are still indisputably dominant. If you want to maximize your developers' experience, it's still too early to _require_ that they use GraphQL because there are going to be a lot of shops out there that are just not set up for it. Of course there is still the option of providing your own libraries and tooling for your users to go through, and if you go with that then the API's implementation is much less important.

Re: Is GraphQL the Next Frontier for Web APIs?

#33

Post by njharman »

bigmanwalter wrote: post #24
Exuma wrote: post #18

Earlier quoted context omitted.

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: fo…

How are your RPC examples not REST?

RPC would involve client lib. And may or may not even use HTTP as transport.

api.get_product(id=1)

api.add_product(details)

Re: Is GraphQL the Next Frontier for Web APIs?

#34

Post by ruslan_talpa »

daurnimator wrote: post #22
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.

Usually when you say CRUD people tend to think "limited functionality" and PostgREST is a bit more then "basic CRUD" as i am sure you know. It's interface is powerful enough to support GraphQL on top (since this is the topic of this thread :) https://subzero.cloud/ )

Re: Is GraphQL the Next Frontier for Web APIs?

#35

Post by bigmanwalter »

njharman wrote: post #33
bigmanwalter wrote: post #24

Earlier quoted context omitted.

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: fo…

How are your RPC examples not REST? RPC would involve client lib. And may or may not even use HTTP as transport. api.get_product(id=1) api.add_product(details)

I thought we were talking about RPC over HTTP. My RPC examples don't qualify as "proper" REST where you are only supposed to GET and POST singular resources at a time. In order to post multiple, you need a collection identifier. In REST, you can't GET "items", you can get "item1" and "item2" or you can get "collection1" to which "item1" and "item2" belong.

Maybe a clearer example around running a script:

REST:

  POST /api/action { action: do_the_thing }
RPC:

  POST /api/do_the_thing
RPC is the most basic mapping of actions > endpoints whereas REST demands you organize everything into resources.

Re: Is GraphQL the Next Frontier for Web APIs?

#36

Post by inf0rmer »

bigmanwalter wrote: post #24
Exuma wrote: post #18

Earlier quoted context omitted.

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: fo…

But that's not how you would use REST and RPC though, you seem to be confusing both paradigms.

REST:

  GET    /api/items   (returns a list of items)
  GET    /api/items/1 (returns item with id#1)
  POST   /api/items   (creates a new item, "adds" it to the list)
  PUT    /api/items/1 (updates item with id#1, the whole resource needs to be sent)
  PATCH  /api/items/1 (updates item with id#1, only changes in the resource need to be sent)
  DELETE /api/items/1 (updates item with id#1, only changes in the resource need to be sent)
RPC (one possible implementation):

  GET  /api/listItems  (lists all items)
  POST /api/addItem    (adds an item)
  POST /api/updateItem (updates an item, the id is in the payload)
  GET  /api/deleteItem (deletes the item)
(Verbs don't matter in RPC, I only used POST in favour of GET in the above examples because some clients and servers enforce limits on the size of GET requests.)

Re: Is GraphQL the Next Frontier for Web APIs?

#37

Post by daxfohl »

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.

Users, for instance. If you think of users as a resource, then updating them is a PUT to /users/{id}. Fine, they can update their info. But you also need a way to change their password. That's a different entrypoint. Where does it go? /users/{id}/password? Is it a PUT or a POST?

I mean, nothing here can't be worked around. Millions of sites do this just fine. But to me, the mental model just doesn't match up. The REST model tries to present a facade that everything is a "resource". In my experience, as apps get bigger, more and more things start not quite fitting that model. You end up having to justify to yourself why certain things go on certain endpoints and soon half your API is REST and half is some hacky REST-RPC hybrid anyway. Starting with an RPC model from the get-go, you avoid these problems.

And note, REST and RPC aren't technologies. REST is a form of RPC, and you can certainly roll your own RPC protocol over REST. They're merely different ways of thinking about and modeling your application.

Re: Is GraphQL the Next Frontier for Web APIs?

#38

Post by ruslan_talpa »

throwaway2016a wrote: post #27

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 in…

If the answer is: "expose both interfaces" then my implementation is exactly it :) GraphQL & REST API for your database (https://subzero.cloud/) At the core sits PostgREST (https://postgrest.com/)

Re: Is GraphQL the Next Frontier for Web APIs?

#39

Post by bigmanwalter »

inf0rmer wrote: post #36
bigmanwalter wrote: post #24

Earlier quoted context omitted.

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: fo…

But that's not how you would use REST and RPC though, you seem to be confusing both paradigms. REST: GET /api/items (returns a list of items) GET /api/items/1 (returns item with id#1) POST /api/items (creates a new item, "adds" it to the list) PUT /api/items/1 (updates item with id#1, the whole resource needs to be sent) PATCH /api/items/1 (updates item with id#1, only changes in the resource need to be sent) DELETE…

Right, but RPC allows for, say, updating items 3, 4, 5, 6 in one request, whereas REST dictates that you do it over 4 separate requests. REST can also get messy if you, let's say, update all items with value > 4 as you can't

  PATCH /api/items/greaterthan/4 { active: false }
Whereas with RPC you can easily do:

  POST /api/items?greaterthan=4 { active: false }
In REST, you would do

  POST /api/item_updates/ { greatherthan: 4, active: false }
It comes off as messy to me as I would prefer to keep all endpoints around manipulating a particular model within the same controller rather than having multiple controllers for each model.

I find there's an impedance mismatch between what endpoints my solutions need and what REST dictates. And it requires a lot of acrobatics to map my solution onto the REST way.

Re: Is GraphQL the Next Frontier for Web APIs?

#40

Post by jraines »

agumonkey wrote: post #11

Clojurescripters liked to leverage GraphQL (david nolen)

More as an inspiration, though. You don't have to define a spec with om.next queries, for example.

Walmart Labs just released a library about a week ago that does actual GraphQL, and there are libraries for the front-end but they aren't widely adopted and not really like Relay, afaik

Post reply on HN