Hacker News Reader

Comment by theptip | Hacker News Reader

Anyone got experience transitioning a large production site from REST to GraphQL? I'm aware Yelp did this recently, wondering about any pain points.

In particular, I have some FUD about how to go about rate limiting, when in theory a single request could grab every resource that the client is authorized to retrieve, and thrash the database.

Looks like Github counts/restricts the number of total nodes returned: https://developer.github.com/v4/guides/resource-limitations/

Also is there any protection against pathological requests? (e.g. if there are loops in the object graph, can I build an arbitrarily deep GraphQL query that will take an arbitrarily long time to complete?)

View on HN

There is a video on the Apollo GraphQL Youtube channel where an engineer from Yelp talks about the process of switching from REST to GraphQL. (Along with a talk from Airbnb, who are currently in the process of the switch.)

https://youtu.be/rapO30fpREg?t=1582

>Also is there any protection against pathological requests? (e.g. if there are loops in the object graph, can I build an arbitrarily deep GraphQL query that will take an arbitrarily long time to complete?)

I've seen some GraphQL servers in the wild that will respond to any query, so it's entirely possible to make abusive queries to bring a server down.

Some attempt to estimate the query complexity, and deny requests based on how long the server thinks it might take. Others, such as Facebook themselves, whitelist which queries are allowed (I have no affiliation with Facebook, this is just what I've heard).

Also in response to protection against malicious requests, you may find the following link helpful.

It goes over several ways to secure your endpoints, along with pros and cons for each.

https://www.howtographql.com/advanced/4-security/

Some random points:

* The caching clients (Relay, Apollo) out there are dog slow for medium to large response payloads. (they're working on it)

* It can add more complexity than you need if used for service<->service chatter (pure RPC may be preferable)

* It's still pretty damn awesome as a data layer, especially to public clients

Thanks to some help from nevir, we are working on a new Store API design that will allow for pluggable stores. Theses stores can be tuned as needed for different performance models.

We are also working on speeding up how the default store handles large response data

Reply on news.ycombinator.com