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

Introducing Yelp's GraphQL API

engineeringblog.yelp.com

Post reply on HN
Print view View original

41–50 of 54 posts

Re: Introducing Yelp's GraphQL API

#41

Post by atticusberg »

abuani wrote: post #34
nowarninglabel wrote: post #21

It's really validating to see Yelp putting a GraphQL API out there as there were a number of questions on whether or not GraphQL made sense as we approached introducing a new API. We (Kiva) also just released our own GraphQL API, though very much in "Beta" it is available at https://api.kivaws.org/graphql with some general API info at https://build.kiva.org We're still working on documentation among other things befo…

I'm not going to lie, this is the first time I've heard of Kiva. Can you talk about some of the reasons why you chose GraphQL and what some of the technical problems that you've solved that were drastically easier in GraphQL vs REST? I'm trying to decide if it's worthwhile internally to consider a GraphQL API build out, but I'd like to get others perspectives on some of the problems that have been significantly easie…

There's nothing that you can do with a RESTful api that can't be done with GraphQL. If you wanted to you could build a RESTful GraphQL api -- we did this at my previous company.

GraphQL allows you to do things though like query for nested data structures without making round trips, require typed arguments for queries, and pass arguments to specific fields, things that would take a bit of doing with a non-GraphQL api.

It's certainly not perfect, for example I at least have found query tuning for large nested queries to be a bit more complicated than I'd like it to be, but overall I've had a really positive experience with it and unless I have a good reason not to will be using it for any apis I'm building going forward.

Re: Introducing Yelp's GraphQL API

#42

Post by MrBuddyCasino »

atticusberg wrote: post #41
abuani wrote: post #34

Earlier quoted context omitted.

I'm not going to lie, this is the first time I've heard of Kiva. Can you talk about some of the reasons why you chose GraphQL and what some of the technical problems that you've solved that were drastically easier in GraphQL vs REST? I'm trying to decide if it's worthwhile internally to consider a GraphQL API build out, but I'd like to get others perspectives on some of the problems that have been significantly easie…

There's nothing that you can do with a RESTful api that can't be done with GraphQL. If you wanted to you could build a RESTful GraphQL api -- we did this at my previous company. GraphQL allows you to do things though like query for nested data structures without making round trips, require typed arguments for queries, and pass arguments to specific fields, things that would take a bit of doing with a non-GraphQL api.…

"There's nothing that you can do with a RESTful api that can't be done with GraphQL"

We discussed GraphQL internally, and came to the conclusion that it mostly makes sense as a performance optimization, which was its original use case, and not as an "alternative" to REST APIs.

Drawbacks:

- you loose the ability to easily cache

- your API is more strongly coupled to your data model, which makes evolving it more difficult

So GraphQL makes sense when

- data size / performance is key

- the app is mature and the data model doesn't change very much

Re: Introducing Yelp's GraphQL API

#43

Post by robzhu »

skrebbel wrote: post #38
andysinclair wrote: post #36

Another option for providing a queryable RESTful API interface is OData http://www.odata.org/

I did some OData a few years ago when it was hip & trendy in .NET land. Right when Facebook announced GraphQL I got a deja vu - our problem with OData was that while the query syntax was awesome, making a server endpoint for it was super hard (unless you happened to be 100% entity framework and wanted all REST data to CRUD straight into the DB and back - which is of course never the case). I now see people on HN have…

> I now see people on HN have very similar complaints about GraphQL - how its power and flexibility makes making a performant and secure GraphQL backend significantly harder than making an oldschool REST API backend.

I'm curious to learn about people who have had this kind of experience with GraphQL, can you please share a link?

> Does anyone have experience with both? Is GraphQL any better than OData in server-side implementability?

OData is complicated, in part, because it includes semantics for querying collections. In GraphQL, it's a little easier to get started by using GraphQL's List type. Later, if you want to pagination/cursors, you can add Connection support (https://facebook.github.io/relay/docs/graphql-connections.ht...).

One very common failure mode we observe with GraphQL users: they do not have a clearly defined boundary between their GraphQL schema definition and their domain layer: http://graphql.org/learn/thinking-in-graphs/#business-logic-...

Re: Introducing Yelp's GraphQL API

#45

Post by nowarninglabel »

abuani wrote: post #34
nowarninglabel wrote: post #21

It's really validating to see Yelp putting a GraphQL API out there as there were a number of questions on whether or not GraphQL made sense as we approached introducing a new API. We (Kiva) also just released our own GraphQL API, though very much in "Beta" it is available at https://api.kivaws.org/graphql with some general API info at https://build.kiva.org We're still working on documentation among other things befo…

I'm not going to lie, this is the first time I've heard of Kiva. Can you talk about some of the reasons why you chose GraphQL and what some of the technical problems that you've solved that were drastically easier in GraphQL vs REST? I'm trying to decide if it's worthwhile internally to consider a GraphQL API build out, but I'd like to get others perspectives on some of the problems that have been significantly easie…

I'd echo the comment down the line a bit for the pros / cons: https://news.ycombinator.com/item?id=14264977

The other non-obvious thing is it has been easier to introduce people to use, especially newer programmers. Being able to walk through examples in the browser, all on the same endpoint, just makes it a lot easier for sharing the concept of getting data. Though it may speak to the fact that our audience is primarily people seeking data, not trying to perform actions.

Re: Introducing Yelp's GraphQL API

#46

Post by zehtomer »

ram_sankar83 wrote: post #31

What language or tech stack has been used to implement this API?

As bpicolo said, lots of Python.

The API itself is a Python service running on Pyramid/uWSGI. Our focus on services internally means that the API delegates our REST requests to other internal services when resolving the data.

As far as the GraphQL implementation, we used Graphene (graphene-python.org) for that.

Re: Introducing Yelp's GraphQL API

#47

Post by ncrmro »

The guy that posted this makes an amazing python package with an additional package for django called graphene and it pretty much handles everything automatically inferring from you django models, it's amazing. I wrote a boilerplate that got me hired and now we are in the process of building out a graphql + Relay Modern app!

Re: Introducing Yelp's GraphQL API

#48

Post by neebz »

MrBuddyCasino wrote: post #42
atticusberg wrote: post #41

Earlier quoted context omitted.

There's nothing that you can do with a RESTful api that can't be done with GraphQL. If you wanted to you could build a RESTful GraphQL api -- we did this at my previous company. GraphQL allows you to do things though like query for nested data structures without making round trips, require typed arguments for queries, and pass arguments to specific fields, things that would take a bit of doing with a non-GraphQL api.…

"There's nothing that you can do with a RESTful api that can't be done with GraphQL" We discussed GraphQL internally, and came to the conclusion that it mostly makes sense as a performance optimization, which was its original use case, and not as an "alternative" to REST APIs. Drawbacks: - you loose the ability to easily cache - your API is more strongly coupled to your data model, which makes evolving it more diffic…

We have struggled from performance perspective because we have a relational database at the back. GraphQL has been limited our overall use of JOINS which means multiple queries to fetch data for different data which could've been fetched in a single JOIN query.

Re: Introducing Yelp's GraphQL API

#49

Post by ruslan_talpa »

neebz wrote: post #48
MrBuddyCasino wrote: post #42

Earlier quoted context omitted.

"There's nothing that you can do with a RESTful api that can't be done with GraphQL" We discussed GraphQL internally, and came to the conclusion that it mostly makes sense as a performance optimization, which was its original use case, and not as an "alternative" to REST APIs. Drawbacks: - you loose the ability to easily cache - your API is more strongly coupled to your data model, which makes evolving it more diffic…

We have struggled from performance perspective because we have a relational database at the back. GraphQL has been limited our overall use of JOINS which means multiple queries to fetch data for different data which could've been fetched in a single JOIN query.

If your database is PostgreSQL (which it should be :P) then https://subzero.cloud might solve that for you. Each GraphQL request is translated to a single database query.

Re: Introducing Yelp's GraphQL API

#50

Post by not_kurt_godel »

Sholmesy wrote: post #30
not_kurt_godel wrote: post #28

Can someone explain why GraphQL was designed to be non-JSON? Seems like a stupid decision, unless I'm missing something.

Your question doesn't really make sense. You are specifying the data that you want back from the API. What gain would be using key:value syntax be in this situation? The request would just be littered with `"requested_data": true` which is just wasteful.

Well, you could do arrays of strings and objects instead of key:value pairs. Although I suppose there would be a lot of superfluous quotes, and part of the point is to optimize for mobile...
Post reply on HN