What is GraphQL? GraphQL is all about data communication Somehow it reminds me of good old "The S stands for Simple": http://harmful.cat-v.org/software/xml/soap/simple
Thank you for reminding me harmful.cat-v exists, this stuff is hilarious.
REST in Peace. Long Live GraphQL
11–20 of 94 posts
Re: REST in Peace. Long Live GraphQL
#12Playful title, but not to be taken literally
Re: REST in Peace. Long Live GraphQL
#13Re: REST in Peace. Long Live GraphQL
#14Typical "RIP older tech, long live new trendy tech" blog posts designed to get beginner experts hyped about something they'll probably never use.
Re: REST in Peace. Long Live GraphQL
#15Anyone 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?)
Re: REST in Peace. Long Live GraphQL
#16Anyone 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?)
Re: REST in Peace. Long Live GraphQL
#17I 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 it?
Re: REST in Peace. Long Live GraphQL
#18Then to read the planet’s name, we ask: GET - /planets/1 And to read the films titles, we ask: GET - /films/1 GET - /films/2 GET - /films/3 GET - /films/6 Once we have all 6 responses from the server, we can combine them to satisfy the data needed by our view. this is stupid there is no need to go multiple rounds?
Yeah, this seems like terrible API design that, while it may be constructed to make a point, sort of obscures whether I should actually care.
GraphQL seems a lot more complicated to consume/explore than REST, and it looks like I need to know a good bit about how the data is shaped before I write a line of code - something that can change, and something that the current REST endpoint system (happily) doesn't need.
Re: REST in Peace. Long Live GraphQL
#19> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. I'm not sure what's different. You can actually implement the same with plain old http api's, also.
You can but you have to write all the allowed query combinations. Graphql is more flexible. It's also declarative, so you can provide a widget with the schema it needs.
Another benefit of graphql is that is a "lingua franka", you can use it internally, between microservices, etc.
Re: REST in Peace. Long Live GraphQL
#20> The need to do multiple round trips to fetch data required by a view: With GraphQL, you can always fetch all the initial data required by a view with a single round-trip to the server. I'm not sure what's different. You can actually implement the same with plain old http api's, also.
Especially since avoiding n+1 query situations involves hand optimizing a lot of stuff anyways. In my experience it's not really any less work than just aggregating stuff in a regular HTTP API, but it does seem to give a better developer experience on the frontend. At a certain scale, I think it could be worth the investment, but I don't think it really lives up to the hype.
well maybe on the frontend it looks good, but on the backend? meh parsing such a query is not painless.
and maybe "simple" queries are looking good and simple, complex and bigger queries and big schema's are really really akward to implement.