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

REST in Peace. Long Live GraphQL

medium.freecodecamp.org

Post reply on HN
Print view View original

31–40 of 94 posts

Re: REST in Peace. Long Live GraphQL

#31

Post by nevir »

theptip wrote: post #15

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

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 serviceservice chatter (pure RPC may be preferable)

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

Re: REST in Peace. Long Live GraphQL

#32

Post by [deleted] »

theptip wrote: post #15

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

[deleted]

Re: REST in Peace. Long Live GraphQL

#33

Post by ruslan_talpa »

baron816 wrote: post #17

I tried to build a GraphQL server, but found it impractical since I didn't want to use Relay or Apollo on the front end. Formatting the query strings just made a mess and was a lot of trouble considering the simple resources I needed. Dealing with authentication and authorization looked like it was going to be a headache as well. I ended up going back to REST. Should I give it another look? Was I too quick to dismiss…

Try PostgREST

Re: REST in Peace. Long Live GraphQL

#34

Post by linkmotif »

baron816 wrote: post #17

I tried to build a GraphQL server, but found it impractical since I didn't want to use Relay or Apollo on the front end. Formatting the query strings just made a mess and was a lot of trouble considering the simple resources I needed. Dealing with authentication and authorization looked like it was going to be a headache as well. I ended up going back to REST. Should I give it another look? Was I too quick to dismiss…

Not sure if you're not going to use it with Apollo/Relay. These clients help you format queries in JS with Babel transforms. These transforms also are what help couple your front end to your back end by validating queries at front end compile time webpack bundling), which is a huge element of the charm imo.

Re: REST in Peace. Long Live GraphQL

#36

Post by daliwali »

theptip wrote: post #15

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

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

Re: REST in Peace. Long Live GraphQL

#38

Post by aarohmankad »

baron816 wrote: post #17

I tried to build a GraphQL server, but found it impractical since I didn't want to use Relay or Apollo on the front end. Formatting the query strings just made a mess and was a lot of trouble considering the simple resources I needed. Dealing with authentication and authorization looked like it was going to be a headache as well. I ended up going back to REST. Should I give it another look? Was I too quick to dismiss…

I've just started building a server/client seed that I can use in the future for my personal projects.

The concerns you have with the front-end are founded. However, you can send a request to a GraphQL endpoint in a very REST-like manner. If you can build a wrapper to create the query as explained in the Stack Overflow post, you can essentially negate the need for Relay/Apollo. (At least until you need any of the helpful tools they provide.)

https://stackoverflow.com/questions/42520663/how-send-graphq...

Re: REST in Peace. Long Live GraphQL

#40

Post by linkmotif »

lolive wrote: post #27

Basically, GraphQL is a revamping of SPARQL (you know, the W3C language to query RDF databases). FYI, DBPedia is a big big endpoint for these old-school technologies. My question is then: - will there be a "standard" way to describe the data model (aka vocabulary) of your GraphQL endpoint? Something like RDFS or OWL.

This is entirely incorrect.

GraphQL is a wrapper around your service layer, or worse, around a number of ad hoc data sources. That service layer or those data sources may query SPARQL services.

Post reply on HN