4 ms·

We avoid this by statically analyzing the queries that are used by the client, generating id’ed persisted queries for them, and only allowing those to be run if

We avoid this by statically analyzing the queries that are used by the client, generating id’ed persisted queries for them, and only allowing those to be run if you’re un-authenticated/a regular user. We also have user roles, which, if you’re an admin, you can run raw queries of whatever you want, but basic users are locked to the persisted query options. It’s pretty cool, definitely adds complexity to our builds/permissions, but it works. We rolled our own, but I think Apollo GraphQL supports this out of the box now. Not saying people should use GraphQL for everything though. It’s kind of overkill for a lot of apps.

PragmaticPulp 4y ago
> We avoid this by statically analyzing the queries that are used by the client, generating id’ed persisted queries for them, and only allowing those to be run if you’re un-authenticated/a regular user. I worked with a team that was going down a similar path. At some point it felt like they were reinventing REST on top of GraphQL with a strict set of predefined queries and result shapes. They hadn't gone too deep into GraphQL tooling so we just switched to REST and implemented those predefined queries. Had a separate, developer-only GraphQL endpoint for prototyping things for a while, but the production stuff was easier to just build out as plain old REST.
- softfalcon 4y ago
  One of the objectives of GraphQL is to replace REST, so yes, you’re right, it’s re-inventing REST. I’m not going to argue whether one is better than the other implementation wise. That’s purely personal preference. GraphQL has one super power though. I have access to an API directly and can save bandwidth by only querying and returning what I explicitly want in the data. That plus the allowed query rules stuff comes free in Apollo GraphQL now. At scale, this is huge for our bandwidth cost savings. A second big win is federation of many GraphQL schemas under one giant god schema. This is useful when you are a big company, merging two architectures with different API’s together under one umbrella. You can define the mappings from the child schemas to the god schema in another spec that has no code, just a federation schema. Again, you can do this in REST too with layered API’s, but GraphQL arguably makes it somewhat easier to do this with just config files. I also find that out of the box, the type safety guarantees of GraphQL are a lot cleaner/batteries include than the REST work I did the many years prior. It’s all do-able with either tech and you are correct in feeling like it’s re-inventing the wheel. It is, and that’s purely a business decision to make money pivoting devs to a new library/environment. I won’t judge you for wanting to stick with REST. It’s tried and true methods that will work for many many use cases. To each their own!
  - arinlen 4y ago
    > I have access to an API directly and can save bandwidth by only querying and returning what I explicitly want in the data. I don't see how REST is not able to do this, not to mention that REST is very well suited for HTTP caching.
  - L0stLink 4y ago
    Saving bandwidth is really not the actual super power. The main advantage is being able to save network requests by fetching all required data in the same request.
    - seelmobile 4y ago
      Agreed - REST APIs can include a field mask or similar for sparse selection on a single entity but you'll still need several requests to fetch fields on related entities.
      - L0stLink 4y ago
        Yes that is the one strength I think GraphQL has that should be undeniable even though I am not a proponent of GraphQL myself.
    - arinlen 4y ago
      > The main advantage is being able to save network requests by fetching all required data in the same request. This is not really GraphQL's selling point. GraphQL's only selling point is this handwaving-driven promise that dev teams no longer need backend work to get an API that returns the data they want. The promise is that frontend teams simply put together a query and the server magically returns what they want. Of course the people promising this magic just so happen to be the same people trying to sell you backend services.
      - L0stLink 4y ago
        I know I can make an API endpoint in Rails equally as fast as writing a query in GraphQL and the code needed to use it. I don't really buy into GraphQL yet since I have not come across a strong enough advantage of using it in my carrier. Although I do see the advantage of basically being able to run SQL through the browser. Unfortunately it is just one of may technologies over hyped by JavaScript developers.

PragmaticPulp 4y ago

> We avoid this by statically analyzing the queries that are used by the client, generating id’ed persisted queries for them, and only allowing those to be run if you’re un-authenticated/a regular user. I worked with a team that was going down a similar path. At some point it felt like they were reinventing REST on top of GraphQL with a strict set of predefined queries and result shapes. They hadn't gone too deep into GraphQL tooling so we just switched to REST and implemented those predefined queries. Had a separate, developer-only GraphQL endpoint for prototyping things for a while, but the production stuff was easier to just build out as plain old REST.

softfalcon 4y ago
One of the objectives of GraphQL is to replace REST, so yes, you’re right, it’s re-inventing REST. I’m not going to argue whether one is better than the other implementation wise. That’s purely personal preference. GraphQL has one super power though. I have access to an API directly and can save bandwidth by only querying and returning what I explicitly want in the data. That plus the allowed query rules stuff comes free in Apollo GraphQL now. At scale, this is huge for our bandwidth cost savings. A second big win is federation of many GraphQL schemas under one giant god schema. This is useful when you are a big company, merging two architectures with different API’s together under one umbrella. You can define the mappings from the child schemas to the god schema in another spec that has no code, just a federation schema. Again, you can do this in REST too with layered API’s, but GraphQL arguably makes it somewhat easier to do this with just config files. I also find that out of the box, the type safety guarantees of GraphQL are a lot cleaner/batteries include than the REST work I did the many years prior. It’s all do-able with either tech and you are correct in feeling like it’s re-inventing the wheel. It is, and that’s purely a business decision to make money pivoting devs to a new library/environment. I won’t judge you for wanting to stick with REST. It’s tried and true methods that will work for many many use cases. To each their own!
- arinlen 4y ago
  > I have access to an API directly and can save bandwidth by only querying and returning what I explicitly want in the data. I don't see how REST is not able to do this, not to mention that REST is very well suited for HTTP caching.
- L0stLink 4y ago
  Saving bandwidth is really not the actual super power. The main advantage is being able to save network requests by fetching all required data in the same request.
  - seelmobile 4y ago
    Agreed - REST APIs can include a field mask or similar for sparse selection on a single entity but you'll still need several requests to fetch fields on related entities.
    - L0stLink 4y ago
      Yes that is the one strength I think GraphQL has that should be undeniable even though I am not a proponent of GraphQL myself.
  - arinlen 4y ago
    > The main advantage is being able to save network requests by fetching all required data in the same request. This is not really GraphQL's selling point. GraphQL's only selling point is this handwaving-driven promise that dev teams no longer need backend work to get an API that returns the data they want. The promise is that frontend teams simply put together a query and the server magically returns what they want. Of course the people promising this magic just so happen to be the same people trying to sell you backend services.
    - L0stLink 4y ago
      I know I can make an API endpoint in Rails equally as fast as writing a query in GraphQL and the code needed to use it. I don't really buy into GraphQL yet since I have not come across a strong enough advantage of using it in my carrier. Although I do see the advantage of basically being able to run SQL through the browser. Unfortunately it is just one of may technologies over hyped by JavaScript developers.