2 ms·

> 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 advan

• 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
          • valenterry 6y ago
            > What stops a frontend developer writing an ad-hoc query? What stops them is that the "ad-hoc" query can only look like this: articlesWithComments($id) { title contents comment { author text } } That's all. Now the only way to change this query is to remove fields but there is no way to make anything more complex. The only way to do more is to repeat the query. I.e. literally: article1: articlesWithComment(1) { title contents comment { author text } } article2: articlesWithComment(2) { title contents comment { author text } } That will create two queries in the backend - that is the equivalent of just making two requests against the same REST route. It _is_ possible to allow a user to change the query like this: articlesWithComments($id) { title contents comment { author { name, age, articles { ... } } text } } But that is totally optional - you don't have to give your users this power.
            • dmitriid 6y ago