4 ms·

This article is so hard to parse. What exactly are the requirements of their desired api solution, both functional and non-functional and how exactly does each

This article is so hard to parse. What exactly are the requirements of their desired api solution, both functional and non-functional and how exactly does each approach solve them? Instead, it’s a meandering journey to their already chosen solution. I can’t tell what their objection to graphql is and why hypermedia API’s are less of a security concern. And their example with json API’s and close coupling doesn’t address the fact that adding a field doesn’t break backwards compatibility, and even if you do need to spin up a new api, any competent architecture will separate rendering an api from the business logic to generate its data, so standing up a new api variation won’t be a huge amount of work.

recursivedoubts 4y ago
> I can’t tell what their objection to graphql is and why hypermedia API’s are less of a security concern. GraphQL increases client-side expressiveness of an API, but it also puts that power in the hands of potentially hostile users who, for example, could open up a console and start crafting dangerous queries (showing data that shouldn't be allowed, creating expensive queries that DoS your system, etc.) Since with hypermedia APIs the UI is produced server side, you can, when producing the HTML, have full access to something like SQL. The server side is a trusted computing environment. Facebook whitelists their GraphQL queries to avoid security issues, but many developers don't even realize that it is one. > And their example with json API’s and close coupling doesn’t address the fact that adding a field doesn’t break backwards compatibility In my example, I remove functionality.
- ec109685 4y ago
  Anyone can watch the traffic go back and forth and see all the hypermedia urls that are present in the response, just like they could hypothetically see the graphql console. However, the smart way to implement graphql is to map queries to a restful url (that’s a simple tool to build), so that the full graph isn’t exposed to end users.
  - recursivedoubts 4y ago
    Again, facebook whitelists every query. Hypermedia URLs are typically specialized and don't expose general query functionality, whereas, as its expressiveness increases, GraphQL approaches the expressiveness of SQL. That's the whole point: you don't want to have to make back end changes to support new front end features. The more powerful you make your GraphQL-based API, the more dangerous the security implications are. The less powerful you make it, the more it fails to address the fundamental problem of requiring back end changes to support front end needs. It boils down to the fact that you simply can't increase the expressiveness of an untrusted computing environment like the browser without increasing security risk, whereas on the server side you can hand full SQL-style query access to your developers.
    - ec109685 4y ago
      Whitelisting doesn’t limit expressiveness at all. It’s part of their build system so it’s a very easy issue to address (especially if you are okay with a manual mapping file).

recursivedoubts 4y ago

> I can’t tell what their objection to graphql is and why hypermedia API’s are less of a security concern. GraphQL increases client-side expressiveness of an API, but it also puts that power in the hands of potentially hostile users who, for example, could open up a console and start crafting dangerous queries (showing data that shouldn't be allowed, creating expensive queries that DoS your system, etc.) Since with hypermedia APIs the UI is produced server side, you can, when producing the HTML, have full access to something like SQL. The server side is a trusted computing environment. Facebook whitelists their GraphQL queries to avoid security issues, but many developers don't even realize that it is one. > And their example with json API’s and close coupling doesn’t address the fact that adding a field doesn’t break backwards compatibility In my example, I remove functionality.

ec109685 4y ago
Anyone can watch the traffic go back and forth and see all the hypermedia urls that are present in the response, just like they could hypothetically see the graphql console. However, the smart way to implement graphql is to map queries to a restful url (that’s a simple tool to build), so that the full graph isn’t exposed to end users.
- recursivedoubts 4y ago
  Again, facebook whitelists every query. Hypermedia URLs are typically specialized and don't expose general query functionality, whereas, as its expressiveness increases, GraphQL approaches the expressiveness of SQL. That's the whole point: you don't want to have to make back end changes to support new front end features. The more powerful you make your GraphQL-based API, the more dangerous the security implications are. The less powerful you make it, the more it fails to address the fundamental problem of requiring back end changes to support front end needs. It boils down to the fact that you simply can't increase the expressiveness of an untrusted computing environment like the browser without increasing security risk, whereas on the server side you can hand full SQL-style query access to your developers.
  - ec109685 4y ago
    Whitelisting doesn’t limit expressiveness at all. It’s part of their build system so it’s a very easy issue to address (especially if you are okay with a manual mapping file).