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

From REST to GraphQL

blog.jacobwgillespie.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: From REST to GraphQL

#31

Post by estefan »

tyre wrote: post #13

> Future Puzzles > Looking forward, here are a few things we are currently looking to solve: > Mutations (Writes) I agree that this is a more compelling way to structure GET requests, but REST and GraphQL are not comparable until they are solving the same problem. Writes are a huge piece of RESTful interfaces (PUT, POST, PATCH, DELETE). I'm happy Facebook is open sourcing their work, but it does a disservice to Graph…

> Writes are a huge piece of RESTful interfaces (PUT, POST, PATCH, DELETE)

GraphQL handles mutations fine. This guy just hasn't implemented them yet.

Re: From REST to GraphQL

#32

Post by gfodor »

It is kind of amazing to me, that we've almost come full circle now from the early days of database driven, server rendered pages. Back then, before ORMs, before even many templating solutions, rendering a page was basically two steps:

- Build usually one, but maybe a few, SQL queries for the database. These queries (as part of their WHERE, GROUP BY, etc clauses) would do the roles of aggregation, summation, and even role based security since the WHERE clause could constrain roles based upon the user's cookie.

- Render the page out by walking this SQL result.

It's been interesting to see the UI layer move out of server rendered pages and into the client, and I do think that moving the web from a "rendering HTML document once" to "in a render loop rendering a DOM" is a step forward not just in flexibility but conceptually. But the data access story is still wildly in flux, and the fact that we are now effectively building a query language and query optimizer that in practice will sit on top of SQL and the RDBMS optimizer makes me feel like this abstraction is definitely too thick. I hope the logical outcome of all this will be a comprehensive data system that ties these pieces together (schema, migration, modelling, performance, data binding, etc.)

I've hoped that this would happen for a while but perhaps as with most things in software engineering a change in the surface syntax and notation (GraphQL) re-frames the problem in the heads of the right people that will be both motivated and able to kill off some sacred cows. I think a data system that draws on the lessons of the RDBMS work of the last several decades, the distributed systems work of just the last decade, while also being in touch with the needs of modern applications has yet to come along -- perhaps it has and I haven't seen it yet.

Re: From REST to GraphQL

#33

Post by andrewingram »

mercurial wrote: post #20
RussianCow wrote: post #19

Earlier quoted context omitted.

This seems to be a common misconception. GraphQL is just a protocol; query fields don't have to be tied to your schema at all, so you don't have to expose anything you don't want to, in the same way that you don't have to make every table accessible via REST.

Let me rephrase that: you are exposing a way to trivially traverse the entire object graph you're exposing through the API, putting you at risk of DOSing your server when your friend Joe the frontend dev makes a small mistake in his query. You can obviously get the same result with REST, but usually you have to work a lot harder for it.

This is actually solvable. The queries that will be executed by an app can be analysed statically, and therefore are available as part of a build pipeline. So it's possible to create a whitelist of queries automatically, or even go one step further and give each query a short unique ID and just say "execute query foo with these parameters" rather than sending the actual body of the query over the network.

Re: From REST to GraphQL

#34

Post by andrewingram »

joesb wrote: post #28

IMO, the enabling library in the article is FaceBook's "DataLoader". When I first saw GraphQL, my thought was that it was a nice abstraction to enable client-dependent API. But it lacks the actual implementation, and provide no answer to "what about performance?" question. DataLoader answer that question elegantly.

Yes, once I stumbled across DataLoader for the first time, I was amazed that what I thought was a major issue for GraphQL had such a straightforward solution.

Re: From REST to GraphQL

#35

Post by andrewingram »

estefan wrote: post #31
tyre wrote: post #13

> Future Puzzles > Looking forward, here are a few things we are currently looking to solve: > Mutations (Writes) I agree that this is a more compelling way to structure GET requests, but REST and GraphQL are not comparable until they are solving the same problem. Writes are a huge piece of RESTful interfaces (PUT, POST, PATCH, DELETE). I'm happy Facebook is open sourcing their work, but it does a disservice to Graph…

> Writes are a huge piece of RESTful interfaces (PUT, POST, PATCH, DELETE) GraphQL handles mutations fine. This guy just hasn't implemented them yet.

Indeed. He implemented a read-only system and wrote it up (very well I might add). Since he hasn't used mutations yet, he didn't feel ready to write about them.

Re: From REST to GraphQL

#37

Post by mercurial »

andrewingram wrote: post #33
mercurial wrote: post #20

Earlier quoted context omitted.

Let me rephrase that: you are exposing a way to trivially traverse the entire object graph you're exposing through the API, putting you at risk of DOSing your server when your friend Joe the frontend dev makes a small mistake in his query. You can obviously get the same result with REST, but usually you have to work a lot harder for it.

This is actually solvable. The queries that will be executed by an app can be analysed statically, and therefore are available as part of a build pipeline. So it's possible to create a whitelist of queries automatically, or even go one step further and give each query a short unique ID and just say "execute query foo with these parameters" rather than sending the actual body of the query over the network.

Yeah, but at that point the quantity of magic will start to make me uncomfortable.

Re: From REST to GraphQL

#38

Post by josevalim »

andyl wrote: post #7

I've heard some rumblings about adding GraphQL as a feature to Elixir / Phoenix. Anyone know more about this?

I am member of the Phoenix team. We are not adding GraphQL to Phoenix. What Chris McCord said in his keynote is that some of the ideas behind GraphQL/Falcor, like co-locating your query with your view, is also useful on the server side because it makes the code more maintainable (for example, you no longer need to write a big query in the controller with knowledge of all the view pieces). It also makes views easier to cache, easier to detect when the cache is expired, easier to compose and so on.

How that will affect Phoenix is yet to be seen but developers shouldn't expect a big departure. In any case, if folks want to build their own package that provides GraphQL/Falcor server and clients on top of Phoenix, by all means, go ahead and have fun!

Re: From REST to GraphQL

#39

Post by simplify »

iamleppert wrote: post #26

If you needed this level of flexibility in your mobile apps, why not just download the datastore to the client and use something like SQLLite, or a JSON query language on the client (similar to mongo, there are lots of options). In addition, in reading the thing that "pushed you over the edge" ... I really don't see how REST has failed you here, in terms of how you are partitioning your data. I can't imagine that som…

This is exactly what I thought too. From what the author described, it seems that they were just using REST incorrectly. When a view wants tags from a playlist, the solution is not to include tags in every other request. You can simply include a query parameter instead:

    GET /playlists/ID?tags=true
This lets the server knows to include the extra information for that request, keeping your original endpoint clean.

We don't know all the details, but from what the author wrote, it seems they were shortsighted to switch to a shiny new tech instead of looking for better ways to refactor what they currently had.

Re: From REST to GraphQL

#40

Post by aikah »

andrewingram wrote: post #33
mercurial wrote: post #20

Earlier quoted context omitted.

Let me rephrase that: you are exposing a way to trivially traverse the entire object graph you're exposing through the API, putting you at risk of DOSing your server when your friend Joe the frontend dev makes a small mistake in his query. You can obviously get the same result with REST, but usually you have to work a lot harder for it.

This is actually solvable. The queries that will be executed by an app can be analysed statically, and therefore are available as part of a build pipeline. So it's possible to create a whitelist of queries automatically, or even go one step further and give each query a short unique ID and just say "execute query foo with these parameters" rather than sending the actual body of the query over the network.

When a solution requires this kind of hacks for a simple task as rate limiting, maybe the solution is a bad one to begin with.

With REST it is fairly easy to do rate limiting on endpoints.

With GraphQL, it is fairly easy to DDOS with a complex query that will ask the server to fetch an insanely complex data structure. And there are no endpoints anymore.

Post reply on HN