6 ms·

GraphQL and the Beads on a String

37 points by luccasiau 3y ago

eddd-ddde 3y ago
If you need to request multiple REST resources for a single "operation", then you don't have enough REST resources defined. [1] Just make another endpoint for getting the whole thing in one go and call it a day, don't try to overly generalise your API. Going even further, your server requests to the database could be similar as well, one query to get everything needed, then you don't even need to worry about server to database distance! [1] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-743 https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
- rbalicki 3y ago
  The problem with REST (or really, any current non GraphQL solution) is there is only an implicit link between the consumer of a field and the query declaration. So, REST queries are append only, especially at large organizations where incremental perf improvements are less good than accidentally bringing down the site is bad. That’s the failure mode of specialized REST endpoints that deliver exactly what a given view needs.
  - eddd-ddde 3y ago
    If you require something more explicit, you can totally define strict schemas that your API adheres to. Would you elaborate on "queries are append only"? I fail to understand the downside you mention. If you mean that you can only append to the data you return from a resource, you can use versioning to deprecate properties on a resource.
- strken 3y ago
  "Make another endpoint for getting the whole thing in one go" is a pretty good description of what GraphQL does. Except instead of writing an endpoint in some general purpose language you define it declaratively.
  - pier25 3y ago
    > is a pretty good description of what GraphQL does Maybe but the implementation is orders of magnitude more complex compared to simply making a couple of DB queries and then sending a JSON.
    - strken 3y ago
      Sure. The implementation of React is orders of magnitude more complex than simply making a couple of HTML templates and sprinkling in vanilla js inside script tags, the implementation of sqlite is orders of magnitude more complex than simply de/serialising your data to a json file, and the implementation of nginx is vastly more complicated than simply exposing a web service directly to the internet. Don't use tools unless you benefit from them. Some people benefit from being able to define JSON responses in a graph query language.
- code_biologist 3y ago
  My practical experience with that idea is pretty negative, at least with any degree of scale (either in how widely used the resource in question is or in number of people working on the system). I saw a multi-year mess made at a company when the widely used `ResourceA` got endpoints for `ResourceAandB` and C, and D, and E... for the reasons you mention. Then somebody added some fields to make a `ResourceA'` with a specific additional feature. Then somebody removed unused fields from `ResourceA'` for better performance, creating different subsets. We ended up with some `ResourceAandC` things moving to the new `A'`, some features did a frontend join with multiple queries, some things moved to a new superset resource named `ResourceA''`. It was a Cambrian explosion of variants of types. Like violence, it ended up being "if one doesn't work, just add more." It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines. GraphQL makes the outcomes of these situations a lot more manageable. In that way I think of it as a social and organizational technology as much as a query technology.
  - dalyons 3y ago
    This is 100% my experience, and this is a very astute observation : > It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines. GraphQL makes the outcomes of these situations a lot more manageable. In that way I think of it as a social and organizational technology as much as a query technology. I think people miss the point a lot when ranting about graphql. It’s not particularly their fault, I didn’t get it either until I experienced multiple massive rest messes like you describe. Also, as social/org tech you don’t really see the benefits in small teams / simple products / small apis. It just feels like extra complexity at that size.
  - jongjong 3y ago
    > It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines. I don't buy this argument. Imagine if an airplane manufacturer had the same philosophy. "We can't just substitute that component because it wouldn't fit the existing frame... Oh but wait, we can't just change the frame or the new component to make it fit because of social factors within the engineering team. Let's just tack it on as originally planned and then work around the issue by implementing a complex solution in the software to make up for the structural design flaw.." That's basically the Boeing 737 MAX story. We know the result of that philosophy.
- Ozzie_osman 3y ago
  > Just make another endpoint for getting the whole thing in one go and call it a day. That's pretty much the point (well, one of the main points) of GraphQL... precisely so you don't have to do that. Want to request a new object or list of objects? Request a new field on an existing object? You don't have to go "make another endpoint", you just change your GraphQL query. This is really nice for iterating, though it does have some downsides (eg it's easy for the person iterating away on the FE to not have to think about the cost of querying that data on the BE). GraphQL does have a few other advantages though, like being able to build your typing around it (again, doable with REST but with more work).
  - eddd-ddde 3y ago
    I also agree with that! I'm not actually opposed to Graphql as a technology, One of my favourite pieces of technology is actually PostGraphile. I just believe it's easy to misuse it (in similar ways to an ORM) that result in not utilising server capabilities to their fullest.
Jonovono 3y ago
I never really got graphql until I stumbled upon Wundergraph. (https://github.com/wundergraph/wundergraph https://github.com/wundergraph/wundergraph). I have no affiliation with them except that I have been building an app with it. I'm honestly puzzled how it's not more popular. Maybe people are solving these problems in other ways? But I tried out a bunch of stuff: Vapor, Supabase, Hasura, firebase, nhost, etc. None of it simplifies building complex systems the way WG does. Once I ship I plan to put together a nice sample repo talking about why I like it, but you can see the WIP here of how I use WG to build a system with (potentially) multiple databases being consumed in a type safe manner from my ios app, nextjs app (and anything else) https://github.com/Jonovono/WGStack https://github.com/Jonovono/WGStack
- jensneuse 3y ago
  I'm one of the WG founders. Thanks for the mention. In case anybody has a question, please ask. (I'm getting a notification if you use the term "WunderGraph")
  - codetrotter 3y ago
    > I'm getting a notification if you use the term "WunderGraph" What happens if I say it three times in a row? Will it summon you to appear in my geographical proximity? WunderGraph WunderGraph WunderGraaaaaaAAAAHHH-
    - deleted 3y ago
      [deleted]
    - SlickStef11 3y ago
      If you say it 3 times, one of the founders will appear behind you with a Federetzel https://twitter.com/meixnertobias/status/1704565814022770857 https://twitter.com/meixnertobias/status/1704565814022770857
    - jensneuse 3y ago
      Say it 5 times and a genie appears who creates you a federated Graph of 100 Microservices although a single boring monolith would have been enough.
015a 3y ago
If the primary selling point of the new technology is something like GraphQL's "if your API doesn't have a good single route to get the data for this page, GraphQL can synthesize it"; frontend just doesn't, in general, iterate at a speed that is such orders-of-magnitude higher than how quickly a new API view can be built, such that a new structurally-different communications layer is necessary. Additionally; GraphQL never got the community love it needed on the backend side to make things hum. Apollo is the only organization really pushing it, and they invest something I'd estimate as 10% of their time into thinking about Apollo Server, which is in any event JavaScript-only. It turns out, the problems GraphQL creates in a system are backend problems; there's some really freakin hairy edges in the domains of authorization, caching, rate limiting/complexity limiting, even just basic type safety, that can only charitably be described as "solved" if you consider "some ideas in a twenty page blog post" as a solution. We also had constant problems educating our customers about GraphQL. "No no, you can use any REST client you want, here let me show you how to set it up" (two hour education session later). There really isn't a perfect solution to the problem space. If your view is complex enough, synthesizing it JIT in GraphQL is just the frontend saying "its your problem now" to the backend, and whether the solution to that is "fixing performance bottlenecks" or "a new RESTful-ish view API for this screen" for the backend team, its still a ticket. If the view is less complex than that: making multiple requests isn't the end of the world. After all, those two highly predictable, optimized, even cached requests may end up being faster than one dynamic and extremely-difficult-to-cache GraphQL request. At the end of the day, I think there's a reason why REST has lasted as long as it has, and why it still feels state of the art to me. Moving more API capabilities to edge platforms, including edge databases, shortens that string of beads quite substantially. Server-side rendering is back is in full force. There's other angles this problem is being attacked from.
- bryanrasmussen 3y ago
  >Additionally; GraphQL never got the community love it needed on the backend side to make things hum. Ok, well for some reason every project I've been on in the past 4-5 years has used GraphQL? What makes me so special? As I conclude that I am not special I have to go back to what my previous position was that GraphQL is pretty much the standard way front-enders query nowadays. That said - the project I am on right now only uses GraphQL for querying CommerceTools, and their GraphQL implementation seems like someone told a dev hey, we need GraphQL, make our SQL backend available over that, and he completed his ticket anywhere from 4 hours to 4 days, but certainly not in any amount of time to make a solution that had any of the advantages of GraphQL in it. We used to have GraphQL for the part of the project using Contentful - but their GraphQL was so problematic we moved to their Rest API (I say was because that move was over 1 year ago, it would be wrong to say it is bad now - who knows what improvements they might have had)
williamcotton 3y ago
I like the RESTful approach taken by Graphiti: Single request and response and with a graph of nested relationships. This approach lets one still use HTTP GET caching, whereas GraphQL hides everything behind a single POST endpoint. https://www.graphiti.dev/guides/ https://www.graphiti.dev/guides/
Omerd6 3y ago
does merging all of your api calls to a single one means that the slowest request is a bottle neck? when splitting your request the user can view his profile picture before the main content finished loading. this cam hurt user experience
- yashap 3y ago
  It absolutely does, and this has been a significant issue when I’ve used GQL.
- akio 3y ago
  You can specify parts of a query should be sent in subsequent responses with the @defer directive, and your client and server libraries will handle the rest for you. Server side: https://the-guild.dev/graphql/yoga-server/docs/features/defer-stream https://the-guild.dev/graphql/yoga-server/docs/features/defe... https://www.apollographql.com/docs/router/executing-operations/defer-support https://www.apollographql.com/docs/router/executing-operatio... Client side: https://www.apollographql.com/docs/react/data/defer https://www.apollographql.com/docs/react/data/defer https://relay.dev/docs/next/glossary/#defer https://relay.dev/docs/next/glossary/#defer
azangru 3y ago
> Which brings some simplicity to the client And puts all the complexity on the backend :-) As far as I've seen, front-end developers are generally quite happy about graphql. Back-end developers on the other hand are a different story.
- asabla 3y ago
  I kind of agree, but at the same time I don't. Before REST API's has always been a situation of discussion ( as in schema and what not, even with openapi). But with GrapQL I've seen more discussion about the schema the anything else. Which is what I prefer as a backend developer. So if GraphQL front-end developers into discussion about schema I rather take that over whatever REST solution they're using today. But I might be biased here...
- luccasiau 3y ago
  I’d say it moves “all the complexity” to the backend if it were defining one REST endpoint for each page the client loads. With GraphQL, each resolver is individually much simpler logic, and there’s no effort to do the stitching. So basically frontend+backend effort with GraphQL is much smaller than frontend+backend with REST
jamil7 3y ago
> You could also define a single REST endpoint that contains all the information to load the page and mimic the GraphQL behavior. But this would just shift the burden of dealing with complexity from the client to the backend. And while that may be viable for simple applications, it would not be in more complex ones. I don't get it, how is this significantly more complex than what the author suggests? How is this shifting complexity to the backend with REST and not with GraphQL if all you're changing is the transport layer?
- hot_gril 3y ago
  GraphQL more clearly makes sense if you're designing some public API used by third-party devs, like Facebook did. It can also make sense for large private APIs. But I wouldn't jump to it unless the "regular" way is presenting problems. Like one time, I was working on a social kind of app. I thought, lemme give a separate endpoint to get each kind of object (user, post, etc) so the client can cache stuff. Frontend devs instead wanted everything needed to render each page in one call, which is understandable. I gave them that, but often they'd later need something I wasn't sending back yet, which slowed down development. So I started sending extra fields back just in case, e.g. sending a full public user object for some page that only needs the name and avatar. In short, it got wasteful, but not the end of the world. GraphQL would've made it cleaner, but it also had an upfront cost.
hipadev23 3y ago
GraphQL is an amazing data exfiltration engine, really a superb OSINT tool.
apimade 3y ago
GraphQL is great for public data and endpoints. Or endpoints that are completely system to system, single-tenant, “we can give the user all the data we hold” integrations. That is, internal integrations where authorization is handled elsewhere. Exposing a GraphQL endpoint has the same issues as exposing a DB. You need to define granularity of access to each individual table, column and row for each user. I’ve yet to find a GraphQL interface that doesn’t expose too much information or fail to follow the principle of least privilege. Even IKEA, who I think has possibly the best GraphQL corporate-built implementation I’ve ever seen, exposes a little too much. Think about your IAM environment and all the exceptions you need to grant users. The same thing exists for data and eventually the ease of use we trade for developers to rapidly prototype results a data breach. Why? Because someone enabled introspection to debug a production issue, or forgot to tick a box or define a parameter when deploying a data model change. Boring old RPC and REST typically doesn’t carry this level of risk, or has tooling to prevent it. As someone who chases bug bounties, please keep building out GraphQL. My mortgage appreciates it. But as someone whose day job is more on the blue-team side - no, you won’t get my sign-off. This is not acceptable risk.
- tshaddox 3y ago
  How does REST solve this any better? As soon as you have certain entities or fields which are visible only to certain subsets of users, surely the problem complexity is essentially the same.
  - apimade 3y ago
    In theory REST doesn’t, in practice it does. The reason why is because most RESTful interfaces are built and deployed separately. You don’t throw an interface on top of a data model and presto, you’ve accidentally exposed your customer data to the internet. The other aspect is with REST the interface is strictly defined. There’s no unknown data being disclosed, you’ve defined the resource and understand the authorization required by building it in the first place. Yes, mistakes are made by engineers who don’t understand what PII is or don’t care what the access control for the endpoint looks like, but at least you can spend time actually scoping it and defining what that looks like. How do you threat model a constantly changing database? You could throw flags on fields and have that tie in with your GQL orchestration lib/tooling, but that’s something that very, very few organisations can get right. Not even 1%, I’d say maybe less than 100 in the world.

37 points by luccasiau 3y ago

If you need to request multiple REST resources for a single "operation", then you don't have enough REST resources defined. [1] Just make another endpoint for getting the whole thing in one go and call it a day, don't try to overly generalise your API. Going even further, your server requests to the database could be similar as well, one query to get everything needed, then you don't even need to worry about server to database distance! [1] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-743 https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

rbalicki 3y ago
The problem with REST (or really, any current non GraphQL solution) is there is only an implicit link between the consumer of a field and the query declaration. So, REST queries are append only, especially at large organizations where incremental perf improvements are less good than accidentally bringing down the site is bad. That’s the failure mode of specialized REST endpoints that deliver exactly what a given view needs.
- eddd-ddde 3y ago
  If you require something more explicit, you can totally define strict schemas that your API adheres to. Would you elaborate on "queries are append only"? I fail to understand the downside you mention. If you mean that you can only append to the data you return from a resource, you can use versioning to deprecate properties on a resource.
strken 3y ago
"Make another endpoint for getting the whole thing in one go" is a pretty good description of what GraphQL does. Except instead of writing an endpoint in some general purpose language you define it declaratively.
- pier25 3y ago
  > is a pretty good description of what GraphQL does Maybe but the implementation is orders of magnitude more complex compared to simply making a couple of DB queries and then sending a JSON.
  - strken 3y ago
    Sure. The implementation of React is orders of magnitude more complex than simply making a couple of HTML templates and sprinkling in vanilla js inside script tags, the implementation of sqlite is orders of magnitude more complex than simply de/serialising your data to a json file, and the implementation of nginx is vastly more complicated than simply exposing a web service directly to the internet. Don't use tools unless you benefit from them. Some people benefit from being able to define JSON responses in a graph query language.
code_biologist 3y ago
My practical experience with that idea is pretty negative, at least with any degree of scale (either in how widely used the resource in question is or in number of people working on the system). I saw a multi-year mess made at a company when the widely used `ResourceA` got endpoints for `ResourceAandB` and C, and D, and E... for the reasons you mention. Then somebody added some fields to make a `ResourceA'` with a specific additional feature. Then somebody removed unused fields from `ResourceA'` for better performance, creating different subsets. We ended up with some `ResourceAandC` things moving to the new `A'`, some features did a frontend join with multiple queries, some things moved to a new superset resource named `ResourceA''`. It was a Cambrian explosion of variants of types. Like violence, it ended up being "if one doesn't work, just add more." It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines. GraphQL makes the outcomes of these situations a lot more manageable. In that way I think of it as a social and organizational technology as much as a query technology.
- dalyons 3y ago
  This is 100% my experience, and this is a very astute observation : > It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines. GraphQL makes the outcomes of these situations a lot more manageable. In that way I think of it as a social and organizational technology as much as a query technology. I think people miss the point a lot when ranting about graphql. It’s not particularly their fault, I didn’t get it either until I experienced multiple massive rest messes like you describe. Also, as social/org tech you don’t really see the benefits in small teams / simple products / small apis. It just feels like extra complexity at that size.
- jongjong 3y ago
  > It's easy to say "don't do that" but shit happens: large legacy codebases, social factors, and individual incentives of backend and frontend teams with deadlines. I don't buy this argument. Imagine if an airplane manufacturer had the same philosophy. "We can't just substitute that component because it wouldn't fit the existing frame... Oh but wait, we can't just change the frame or the new component to make it fit because of social factors within the engineering team. Let's just tack it on as originally planned and then work around the issue by implementing a complex solution in the software to make up for the structural design flaw.." That's basically the Boeing 737 MAX story. We know the result of that philosophy.
Ozzie_osman 3y ago
> Just make another endpoint for getting the whole thing in one go and call it a day. That's pretty much the point (well, one of the main points) of GraphQL... precisely so you don't have to do that. Want to request a new object or list of objects? Request a new field on an existing object? You don't have to go "make another endpoint", you just change your GraphQL query. This is really nice for iterating, though it does have some downsides (eg it's easy for the person iterating away on the FE to not have to think about the cost of querying that data on the BE). GraphQL does have a few other advantages though, like being able to build your typing around it (again, doable with REST but with more work).
- eddd-ddde 3y ago
  I also agree with that! I'm not actually opposed to Graphql as a technology, One of my favourite pieces of technology is actually PostGraphile. I just believe it's easy to misuse it (in similar ways to an ORM) that result in not utilising server capabilities to their fullest.

Jonovono 3y ago

I never really got graphql until I stumbled upon Wundergraph. (https://github.com/wundergraph/wundergraph https://github.com/wundergraph/wundergraph). I have no affiliation with them except that I have been building an app with it. I'm honestly puzzled how it's not more popular. Maybe people are solving these problems in other ways? But I tried out a bunch of stuff: Vapor, Supabase, Hasura, firebase, nhost, etc. None of it simplifies building complex systems the way WG does. Once I ship I plan to put together a nice sample repo talking about why I like it, but you can see the WIP here of how I use WG to build a system with (potentially) multiple databases being consumed in a type safe manner from my ios app, nextjs app (and anything else) https://github.com/Jonovono/WGStack https://github.com/Jonovono/WGStack

jensneuse 3y ago
I'm one of the WG founders. Thanks for the mention. In case anybody has a question, please ask. (I'm getting a notification if you use the term "WunderGraph")
- codetrotter 3y ago
  > I'm getting a notification if you use the term "WunderGraph" What happens if I say it three times in a row? Will it summon you to appear in my geographical proximity? WunderGraph WunderGraph WunderGraaaaaaAAAAHHH-
  - deleted 3y ago
    [deleted]
  - SlickStef11 3y ago
    If you say it 3 times, one of the founders will appear behind you with a Federetzel https://twitter.com/meixnertobias/status/1704565814022770857 https://twitter.com/meixnertobias/status/1704565814022770857
  - jensneuse 3y ago
    Say it 5 times and a genie appears who creates you a federated Graph of 100 Microservices although a single boring monolith would have been enough.

015a 3y ago

If the primary selling point of the new technology is something like GraphQL's "if your API doesn't have a good single route to get the data for this page, GraphQL can synthesize it"; frontend just doesn't, in general, iterate at a speed that is such orders-of-magnitude higher than how quickly a new API view can be built, such that a new structurally-different communications layer is necessary. Additionally; GraphQL never got the community love it needed on the backend side to make things hum. Apollo is the only organization really pushing it, and they invest something I'd estimate as 10% of their time into thinking about Apollo Server, which is in any event JavaScript-only. It turns out, the problems GraphQL creates in a system are backend problems; there's some really freakin hairy edges in the domains of authorization, caching, rate limiting/complexity limiting, even just basic type safety, that can only charitably be described as "solved" if you consider "some ideas in a twenty page blog post" as a solution. We also had constant problems educating our customers about GraphQL. "No no, you can use any REST client you want, here let me show you how to set it up" (two hour education session later). There really isn't a perfect solution to the problem space. If your view is complex enough, synthesizing it JIT in GraphQL is just the frontend saying "its your problem now" to the backend, and whether the solution to that is "fixing performance bottlenecks" or "a new RESTful-ish view API for this screen" for the backend team, its still a ticket. If the view is less complex than that: making multiple requests isn't the end of the world. After all, those two highly predictable, optimized, even cached requests may end up being faster than one dynamic and extremely-difficult-to-cache GraphQL request. At the end of the day, I think there's a reason why REST has lasted as long as it has, and why it still feels state of the art to me. Moving more API capabilities to edge platforms, including edge databases, shortens that string of beads quite substantially. Server-side rendering is back is in full force. There's other angles this problem is being attacked from.

bryanrasmussen 3y ago
>Additionally; GraphQL never got the community love it needed on the backend side to make things hum. Ok, well for some reason every project I've been on in the past 4-5 years has used GraphQL? What makes me so special? As I conclude that I am not special I have to go back to what my previous position was that GraphQL is pretty much the standard way front-enders query nowadays. That said - the project I am on right now only uses GraphQL for querying CommerceTools, and their GraphQL implementation seems like someone told a dev hey, we need GraphQL, make our SQL backend available over that, and he completed his ticket anywhere from 4 hours to 4 days, but certainly not in any amount of time to make a solution that had any of the advantages of GraphQL in it. We used to have GraphQL for the part of the project using Contentful - but their GraphQL was so problematic we moved to their Rest API (I say was because that move was over 1 year ago, it would be wrong to say it is bad now - who knows what improvements they might have had)

williamcotton 3y ago

I like the RESTful approach taken by Graphiti: Single request and response and with a graph of nested relationships. This approach lets one still use HTTP GET caching, whereas GraphQL hides everything behind a single POST endpoint. https://www.graphiti.dev/guides/ https://www.graphiti.dev/guides/

Omerd6 3y ago

does merging all of your api calls to a single one means that the slowest request is a bottle neck? when splitting your request the user can view his profile picture before the main content finished loading. this cam hurt user experience

yashap 3y ago
It absolutely does, and this has been a significant issue when I’ve used GQL.
akio 3y ago
You can specify parts of a query should be sent in subsequent responses with the @defer directive, and your client and server libraries will handle the rest for you. Server side: https://the-guild.dev/graphql/yoga-server/docs/features/defer-stream https://the-guild.dev/graphql/yoga-server/docs/features/defe... https://www.apollographql.com/docs/router/executing-operations/defer-support https://www.apollographql.com/docs/router/executing-operatio... Client side: https://www.apollographql.com/docs/react/data/defer https://www.apollographql.com/docs/react/data/defer https://relay.dev/docs/next/glossary/#defer https://relay.dev/docs/next/glossary/#defer

azangru 3y ago

> Which brings some simplicity to the client And puts all the complexity on the backend :-) As far as I've seen, front-end developers are generally quite happy about graphql. Back-end developers on the other hand are a different story.

asabla 3y ago
I kind of agree, but at the same time I don't. Before REST API's has always been a situation of discussion ( as in schema and what not, even with openapi). But with GrapQL I've seen more discussion about the schema the anything else. Which is what I prefer as a backend developer. So if GraphQL front-end developers into discussion about schema I rather take that over whatever REST solution they're using today. But I might be biased here...
luccasiau 3y ago
I’d say it moves “all the complexity” to the backend if it were defining one REST endpoint for each page the client loads. With GraphQL, each resolver is individually much simpler logic, and there’s no effort to do the stitching. So basically frontend+backend effort with GraphQL is much smaller than frontend+backend with REST

jamil7 3y ago

> You could also define a single REST endpoint that contains all the information to load the page and mimic the GraphQL behavior. But this would just shift the burden of dealing with complexity from the client to the backend. And while that may be viable for simple applications, it would not be in more complex ones. I don't get it, how is this significantly more complex than what the author suggests? How is this shifting complexity to the backend with REST and not with GraphQL if all you're changing is the transport layer?

hot_gril 3y ago
GraphQL more clearly makes sense if you're designing some public API used by third-party devs, like Facebook did. It can also make sense for large private APIs. But I wouldn't jump to it unless the "regular" way is presenting problems. Like one time, I was working on a social kind of app. I thought, lemme give a separate endpoint to get each kind of object (user, post, etc) so the client can cache stuff. Frontend devs instead wanted everything needed to render each page in one call, which is understandable. I gave them that, but often they'd later need something I wasn't sending back yet, which slowed down development. So I started sending extra fields back just in case, e.g. sending a full public user object for some page that only needs the name and avatar. In short, it got wasteful, but not the end of the world. GraphQL would've made it cleaner, but it also had an upfront cost.

hipadev23 3y ago

GraphQL is an amazing data exfiltration engine, really a superb OSINT tool.

apimade 3y ago

GraphQL is great for public data and endpoints. Or endpoints that are completely system to system, single-tenant, “we can give the user all the data we hold” integrations. That is, internal integrations where authorization is handled elsewhere. Exposing a GraphQL endpoint has the same issues as exposing a DB. You need to define granularity of access to each individual table, column and row for each user. I’ve yet to find a GraphQL interface that doesn’t expose too much information or fail to follow the principle of least privilege. Even IKEA, who I think has possibly the best GraphQL corporate-built implementation I’ve ever seen, exposes a little too much. Think about your IAM environment and all the exceptions you need to grant users. The same thing exists for data and eventually the ease of use we trade for developers to rapidly prototype results a data breach. Why? Because someone enabled introspection to debug a production issue, or forgot to tick a box or define a parameter when deploying a data model change. Boring old RPC and REST typically doesn’t carry this level of risk, or has tooling to prevent it. As someone who chases bug bounties, please keep building out GraphQL. My mortgage appreciates it. But as someone whose day job is more on the blue-team side - no, you won’t get my sign-off. This is not acceptable risk.

tshaddox 3y ago
How does REST solve this any better? As soon as you have certain entities or fields which are visible only to certain subsets of users, surely the problem complexity is essentially the same.
- apimade 3y ago
  In theory REST doesn’t, in practice it does. The reason why is because most RESTful interfaces are built and deployed separately. You don’t throw an interface on top of a data model and presto, you’ve accidentally exposed your customer data to the internet. The other aspect is with REST the interface is strictly defined. There’s no unknown data being disclosed, you’ve defined the resource and understand the authorization required by building it in the first place. Yes, mistakes are made by engineers who don’t understand what PII is or don’t care what the access control for the endpoint looks like, but at least you can spend time actually scoping it and defining what that looks like. How do you threat model a constantly changing database? You could throw flags on fields and have that tie in with your GQL orchestration lib/tooling, but that’s something that very, very few organisations can get right. Not even 1%, I’d say maybe less than 100 in the world.