4 ms·

I also much prefer simple REST APIs, just much easier to understand among other things. (e.g. fetch("/api/users").then(...) and it's good to go)

exogen 8y ago
It's certainly easier to start out that way. But there are also a lot of pitfalls, that systems like what's described in the article are designed to solve. For example: let's say when component A or component B get rendered, they need to fetch users in order to show something about them. You only want to make the request if either of these components is actually rendered on the screen. What if they both get rendered? Is something going to know to reuse the inflight request so you don't have two identical requests? Or is it just naively going to make unnecessary requests? What if some other thing already fetched the user list earlier, are either of them still going to make the request anyway? Or use the data that's already there? Another example: you've got your result from the users endpoint. Now you fetch some user information from the "blog author" endpoint. Information about the same user is in both responses. What's the authoritative client-side source of information about that user now? Are you now going to potentially be displaying stale/conflicting info about that user in 2+ different places? etc. You can always just keep things simple if you want, and people in React and GraphQL land are happy to do that, too. But a lot of people are also focused on building complex applications. This is just to give you some perspective on the "why" here.
- aboutruby 8y ago
  In my cases, for 1) and 2) the parent component would be fetching the user and passing it down to the child components.
  - exogen 8y ago
    For (1), how does the parent know whether those components will actually be rendered? Keep in mind one of the requirements was "only fetch if they're actually rendered." Presumably some other components along the way could be deciding to conditionally render them, right? For (2), the complexity is still there, just in the parent: it needs an entity store and to merge/invalidate when the same entity appears in multiple responses. So still not just a simple case of making some REST API calls.
    - ludwigvan 8y ago
      > For (1), how does the parent know whether those components will actually be rendered? Well, usually parent decides whether the children will be rendered or not.
      - exogen 8y ago
        All the conditionals in your rendering are at the very top level..?
- shaunpersad 8y ago
  > Is something going to know to reuse the inflight request so you don't have two identical requests? I really don't see what GraphQL has to do with this problem. What you're describing are issues that pop up with any external datastore. GraphQL is just a protocol. If there are clients that take care of that type of caching, that's an implementation detail. You can also have REST clients that do the same. > Are you now going to potentially be displaying stale/conflicting info about that user in 2+ different places? If you knew you needed info about the user as a blog author as well, you could've included that in the users request. Isn't that what you would've done in GraphQL anyway? I'm not trying to detract from GraphQL's usefulness, but you can accomplish the same things in REST pretty easily too, especially if you control both server and client code. IMO, GraphQL really shines when you're implementing clients for APIs that you don't already control. In that case, the flexibility is great. But if you're building both the APIs and the clients, REST works (and has worked) pretty easily.
  - exogen 8y ago
    Indeed! I wasn't talking about REST vs. GraphQL at all, but rather the benefit that fancy clients get you (notice I said "systems like what's described in the article", not GraphQL in general). I think that's what the grandparents were talking about, since the boilerplate they were discussing presumably comes from Apollo, not GraphQL. Apollo is a fancy client like you describe.
mattbillenstein 8y ago
GraphQL removes a lot of the REST boilerplate on the backend -- you define the graphql schema, and the clients can fetch it in any shape they want -- especially helpful for supporting different clients that want the data in different shapes depending on what the view is. ie, a web vs mobile view, or a customer web view vs one that might be for internal tools, etc
- aboutruby 8y ago
  I prefer having either too much information in the response for each case (I'm not operating at Google/Facebook-scale), and then other endpoints for sub-resources (both individual and lists).

exogen 8y ago

It's certainly easier to start out that way. But there are also a lot of pitfalls, that systems like what's described in the article are designed to solve. For example: let's say when component A or component B get rendered, they need to fetch users in order to show something about them. You only want to make the request if either of these components is actually rendered on the screen. What if they both get rendered? Is something going to know to reuse the inflight request so you don't have two identical requests? Or is it just naively going to make unnecessary requests? What if some other thing already fetched the user list earlier, are either of them still going to make the request anyway? Or use the data that's already there? Another example: you've got your result from the users endpoint. Now you fetch some user information from the "blog author" endpoint. Information about the same user is in both responses. What's the authoritative client-side source of information about that user now? Are you now going to potentially be displaying stale/conflicting info about that user in 2+ different places? etc. You can always just keep things simple if you want, and people in React and GraphQL land are happy to do that, too. But a lot of people are also focused on building complex applications. This is just to give you some perspective on the "why" here.

aboutruby 8y ago
In my cases, for 1) and 2) the parent component would be fetching the user and passing it down to the child components.
- exogen 8y ago
  For (1), how does the parent know whether those components will actually be rendered? Keep in mind one of the requirements was "only fetch if they're actually rendered." Presumably some other components along the way could be deciding to conditionally render them, right? For (2), the complexity is still there, just in the parent: it needs an entity store and to merge/invalidate when the same entity appears in multiple responses. So still not just a simple case of making some REST API calls.
  - ludwigvan 8y ago
    > For (1), how does the parent know whether those components will actually be rendered? Well, usually parent decides whether the children will be rendered or not.
    - exogen 8y ago
      All the conditionals in your rendering are at the very top level..?
shaunpersad 8y ago
> Is something going to know to reuse the inflight request so you don't have two identical requests? I really don't see what GraphQL has to do with this problem. What you're describing are issues that pop up with any external datastore. GraphQL is just a protocol. If there are clients that take care of that type of caching, that's an implementation detail. You can also have REST clients that do the same. > Are you now going to potentially be displaying stale/conflicting info about that user in 2+ different places? If you knew you needed info about the user as a blog author as well, you could've included that in the users request. Isn't that what you would've done in GraphQL anyway? I'm not trying to detract from GraphQL's usefulness, but you can accomplish the same things in REST pretty easily too, especially if you control both server and client code. IMO, GraphQL really shines when you're implementing clients for APIs that you don't already control. In that case, the flexibility is great. But if you're building both the APIs and the clients, REST works (and has worked) pretty easily.
- exogen 8y ago
  Indeed! I wasn't talking about REST vs. GraphQL at all, but rather the benefit that fancy clients get you (notice I said "systems like what's described in the article", not GraphQL in general). I think that's what the grandparents were talking about, since the boilerplate they were discussing presumably comes from Apollo, not GraphQL. Apollo is a fancy client like you describe.

mattbillenstein 8y ago

GraphQL removes a lot of the REST boilerplate on the backend -- you define the graphql schema, and the clients can fetch it in any shape they want -- especially helpful for supporting different clients that want the data in different shapes depending on what the view is. ie, a web vs mobile view, or a customer web view vs one that might be for internal tools, etc

aboutruby 8y ago
I prefer having either too much information in the response for each case (I'm not operating at Google/Facebook-scale), and then other endpoints for sub-resources (both individual and lists).