4 ms·

I think it's the flexible middle-ground that REST APIs and GraphQL APIs converge on. GraphQL APIs that are completely open are trivially DOS'd with recursive d

I think it's the flexible middle-ground that REST APIs and GraphQL APIs converge on. GraphQL APIs that are completely open are trivially DOS'd with recursive data loops or deeply nested over-fetching requests and hence need to be restricted down to acceptable shapes -- thus converging on essentially the same solution from the opposite direction when constructing a GraphQL API.

dartos 2y ago
> trivially DOS'd with recursive data loops or deeply nested over-fetching requests The depth of recursion can be limited in servers like Apollo. Maybe “trivally easy to misconfigure”
- eYrKEC2 2y ago
  Yeah. First you limit the depth of recursion. Then you limit which objects can nest which other objects, under which circumstances.. Pretty soon -- you have a proscribed set of shapes that you allow... and you've converged on the same solution as achieved in the other direction by the REST API requiring explicit data shape inclusion from the caller.
  - dartos 2y ago
    That’s a slippery slope that I don’t think holds up. When designing the schema, you keep performance and security in mind. You need to do the same for REST APIs. Just because some nodes don’t have edges that connect to some other nodes does not mean you’re back at REST. The main benefit of graphql in not creating super rigid contracts between the frontend and the backend or between services is maintained.
  - tshaddox 2y ago
    > and you've converged on the same solution as achieved in the other direction by the REST API requiring explicit data shape inclusion from the caller. Yes, and with GraphQL you didn't have to invent your own way to represent the syntax and semantics in the query string, and you get to use the GraphQL type system and tooling.
tshaddox 2y ago
Don't most production-ready GraphQL servers have some sort of static query cost estimator that is intended to be hooked up to a rate limiter? At the bare minimum, it should be very easy to set up simple breadth+depth limits per request. This doesn't seem meaningfully more complex than rate limiting a REST API, especially a REST API with configurable "includes."

dartos 2y ago

> trivially DOS'd with recursive data loops or deeply nested over-fetching requests The depth of recursion can be limited in servers like Apollo. Maybe “trivally easy to misconfigure”

eYrKEC2 2y ago
Yeah. First you limit the depth of recursion. Then you limit which objects can nest which other objects, under which circumstances.. Pretty soon -- you have a proscribed set of shapes that you allow... and you've converged on the same solution as achieved in the other direction by the REST API requiring explicit data shape inclusion from the caller.
- dartos 2y ago
  That’s a slippery slope that I don’t think holds up. When designing the schema, you keep performance and security in mind. You need to do the same for REST APIs. Just because some nodes don’t have edges that connect to some other nodes does not mean you’re back at REST. The main benefit of graphql in not creating super rigid contracts between the frontend and the backend or between services is maintained.
- tshaddox 2y ago
  > and you've converged on the same solution as achieved in the other direction by the REST API requiring explicit data shape inclusion from the caller. Yes, and with GraphQL you didn't have to invent your own way to represent the syntax and semantics in the query string, and you get to use the GraphQL type system and tooling.

tshaddox 2y ago

Don't most production-ready GraphQL servers have some sort of static query cost estimator that is intended to be hooked up to a rate limiter? At the bare minimum, it should be very easy to set up simple breadth+depth limits per request. This doesn't seem meaningfully more complex than rate limiting a REST API, especially a REST API with configurable "includes."