If I understand GraphQL correctly, it sounds like I will be re-writing queries multiple times across different clients (android/ios/web). For the majority of (simple) read operations this doesn't seem like such a big deal. But for write operations, wouldn't this mean having business logic repeated across clients? If so, I don't like that.
REST in Peace. Long Live GraphQL
61–70 of 94 posts
Re: REST in Peace. Long Live GraphQL
#62The article starts with:
> With GraphQL, the client speaks a request language which: 1) eliminates the need for the server to hardcode the shape or size of the data
And then ends with: > There are some mitigations we can do here. We can do cost analysis on the query in advance and enforce some kind of limits on the amount of data one can consume.
... so basically you did nothing in the way of perf but add complexity.
Re: REST in Peace. Long Live GraphQL
#63There is a lot of FUD from the GraphQL side of this debate, and even overlapping goals with REST. From the article:
>With GraphQL, the client speaks a request language which decouples clients from servers. This means we can maintain and improve clients separately from servers.
This is actually how the web works right now. Browsers (clients) evolve independently from web pages (servers). Even the author of REST said it is "intended to promote software longevity and independent evolution". Standards are governed by standards bodies such as IETF, IANA, W3C, WHATWG, etc., not a single corporation like Facebook.
I think only time will tell if this is just another fad that took off but didn't age well, like SOAP.
Re: REST in Peace. Long Live GraphQL
#64I've often wondered about this example: 1) Relational databases already had network interfaces 2) SQL isn't perfect, but it has been reliable for a long time 3) Why we didn't increase the performance and security of SQL interfaces, relational databases and just expose those to client applications, including in the browser, directly? Ok, there are a lot of reasons. I worked on a project once that was essentially a "da…
about exposing databases directly, https://postgrest.com comes quite close to what you are describing
Re: REST in Peace. Long Live GraphQL
#65The JSON API specification resolves the 2 major problems people have with REST:
The need for multiple round-trips to the server and sparse field-sets (returning only the fields needed):
http://jsonapi.org/format/#fetching-includes http://jsonapi.org/format/#fetching-sparse-fieldsets
Re: REST in Peace. Long Live GraphQL
#66Why not just expose SQL? Only half kidding. I mean, you can set permissions and everything.
Re: REST in Peace. Long Live GraphQL
#67I'm pretty disappointed by this title. I know that it might be said in fun - and is an easy way to get clicks, but it feeds into the narrative of new, shiny tech. As the article points out at the end, there are very real engineering tradeoffs with GraphQL - and the answer isn't as easy as REST is dead, anachronistic technology that no engineer should consider (the XML analogy felt particularly inflammatory). Kelly an…
Yeah, it's really unfortunate that people feel the need to trash other technologies when promoting something.
I'm a big fan of GraphQL and tried to write up a more low-level comparison here: https://dev-blog.apollodata.com/graphql-vs-rest-5d425123e34b
Re: REST in Peace. Long Live GraphQL
#68I'm pretty disappointed by this title. I know that it might be said in fun - and is an easy way to get clicks, but it feeds into the narrative of new, shiny tech. As the article points out at the end, there are very real engineering tradeoffs with GraphQL - and the answer isn't as easy as REST is dead, anachronistic technology that no engineer should consider (the XML analogy felt particularly inflammatory). Kelly an…
>A number of "engineering" posts are not written as a thoughtful engineer might, and are in many ways marketing for the products sold (like a training program).
I think this is a great insight that is often overlooked in tech marketing. When any vendor comes up with a product that claims "[industry standard] is dead, use [our product]", there should be alarm bells ringing already.
Re: REST in Peace. Long Live GraphQL
#69Anyone 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 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
Re: REST in Peace. Long Live GraphQL
#70I 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…
One thing that may be helpful is a smaller client like Apollo-link (https://github.com/apollographql/apollo-link) that can grow to fit your client needs.
The basic http link includes middleware for passing auth to the server.
I hope that helps!