5 ms·

Agreed with this, you definitely don't want to be the one implementing it on the backend it is no fun at all and can be quite tricky with all the n+1 you didnt

• valenterry 6y ago
  The n+1 would be there with REST too. Unless you have specific, optimized REST routes - but then you can do the same with specific, optimized graphQL queries too.
  • anamexis 6y ago
    Well, I would argue with "true" REST, all of your REST routes are specific, and generally therefore easy to optimize.
    • valenterry 6y ago
      Why would your routes with REST magically be specific and your queries with GraphQL not?
      • dyeje 6y ago
        REST endpoints typically return a specific set of data that you can optimize queries for. Whereas the GraphQL endpoint must handle arbitrary queries which will require some logic to prevent N+1 queries on the related tables or even resolve to other data sources.
        • valenterry 6y ago
          > REST endpoints typically return a specific set of data that you can optimize queries for You mean when someone creates a REST API he magically knows in advance how it will be used and writes a bunch of specific, optimized endpoints and queries such as "/magic-endpoint/" which returns 20 blogposts with their comments? I don't think so. And even if that were true, the same could easily be done with GraphQL.
          • dyeje 6y ago
            It's not magic, you would design it in advance so you know what you're querying by and what you're returning in the payload. Typically you'd probably separate it into two endpoints `/blogposts` and `/blogposts/:id/comments`, but there are many ways to approach the problem. These days JSON:API is pretty popular for creating standard interfaces.
            • valenterry 6y ago
              > It's not magic, you would design it in advance so you know what you're querying by and what you're returning in the payload Where is the difference to GraphQL then? If you know in advance what will be queried then you can create an optimized query for it.
              • dmitriid 6y ago
                > Where is the difference to GraphQL then? GraphQL allows ad-hoc queries of unlimited complexity and recursion > If you know in advance what will be queried then you can create an optimized query for it. No. In general you don't know what will be queried. And that's the reason why most GraphQL implementations end up using just a small predefined set of "persisted queries" (that is, REST with extra steps).
                • valenterry 6y ago
                  I think you misunderstand. You can write very restricted queries that mirror REST routes 1:1. No need for persisted queries. Persisted queries enter the game when you define a query that potentially can become very complex and deep and then want to restrict the complexity in specific ways. But that is not required if you just want to mirror a RESTful API.
                  • dmitriid 6y ago
                    > I think you misunderstand. I don't > You can write very restricted queries that mirror REST routes 1:1. No need for persisted queries. What stops a frontend developer writing an ad-hoc query? > Persisted queries enter the game when you define a query that potentially can become very complex and deep That... That is exactly what I wrote. --- Honestly, I'm baffled at GraphQL defenders. It's like they never even read the documentation to the tools they defend. - How is GraphQL different from REST? - Ad-hoc queries of unlimited complexity - But you write restricted queries - No. The whole point of GraphQL is ad-hoc queries - Persisted queries enter the game when you define a query that potentially can become very complex and deep - That is exactly what I'm saying And elsewhere, you can see it in other replies, it's the same story with N+1: - GraphQL is great! - Except the issues on the server and trying to handle N+1 queries - What's N+1? - It's.... It's a prominent part of the documentation for the frigging tool you use. And the reason for the things you advocate like dataloaders and persisted queries
        • talaketu 6y ago
          REST endpoints typically return data I don't need. For example, the twitter REST API `/1.1/users/show.json?screen_name=twitterdev` it will show me the last tweet for the user. Presumably this involves perhaps waiting for tweet service when the client may not even want the tweet. A GraphQL client can be more explicit about what edges to select.
          • fiddlerwoaroof 6y ago
            There are specs like jsonapi that solve this problem. I’ve never been entirely convinced that GraphQL is better than actual REST, even if it’s better than most of the APIs people call RESTful
            • tshaddox 6y ago
              JSON:API provides some of the same functionality as GraphQL, like specifying which fields and nested resources you want, but at that point you’re going to have the same problems with ensuring good performance with any combination of included fields and relationships.
              • fiddlerwoaroof 6y ago
                I don’t disagree: I tend to find REST + openapi codegen a more compelling developer experience then yet another query DSL.
            • collyw 6y ago
              > even if it’s better than most of the APIs people call RESTful I feel your pain.
          • dyeje 6y ago
            Yes, the advantage of a GraphQL endpoint is you can ask for a variety of things and the tradeoff is potential performance issues for unforeseen queries doing N+1s or something. If you control the API and know all the use cases for a REST endpoint, the advantage is predictable performance characteristics and the tradeoff is flexibility. It all depends on what you need (and maybe what tools you're using to mitigate GraphQL resolver problems).