3 ms·

2016 would be the rise of GraphQL or Falcor backends, where you write exactly what you are looking for on the frontend and send that request to the backend inst

by sync 11y ago

2016 would be the rise of GraphQL or Falcor backends, where you write exactly what you are looking for on the frontend and send that request to the backend instead of REST endpoints. http://graphql.org/ http://graphql.org/ http://netflix.github.io/falcor/ http://netflix.github.io/falcor/

steven777400 11y ago
This is a pretty neat idea. It seems like it would be a lot harder to reason about than REST endpoints. I'm particularly thinking about validation (beyond the type-level, like when other data could conflict with a change) and security issues. What kinds of techniques are used to approach these concerns? Both examples seem to be completely JavaScript-centric on the server side, but it seems like there's no reason it shouldn't work with different backend languages.
- andrewingram 11y ago
  GraphQL servers exist in multiple languages, many of them have more mature implementations than the reference (JavaScript)server. Sangria (the Scala implementation) is particularly impressive. And one of the Elixir implementations, Absinthe, is coming along very nicely. The main security concerns are: * Data leakage, the GraphQL schema reveals the overall capabilities of your system, which may not be desirable. It may still be necessary to split into private/public implementations. * Denial-of-service. Unless you take steps to mitigate it (there are a few approaches out there), it's often trivial to construct a query that could bring down a server. The two main approaches i've seen are white-listing queries at build time (so clients can't construct arbitrary queries), and adding cost/complexity heuristics to the server and rejecting any query over a certain threshold. * Authentication. Not actually a new concern, because the issue is basically the same as with REST. But you do need to get authentication and permissioning properly designed on the backend, it's not something you can really defer until a later date.

by sync 11y ago

steven777400 11y ago

This is a pretty neat idea. It seems like it would be a lot harder to reason about than REST endpoints. I'm particularly thinking about validation (beyond the type-level, like when other data could conflict with a change) and security issues. What kinds of techniques are used to approach these concerns? Both examples seem to be completely JavaScript-centric on the server side, but it seems like there's no reason it shouldn't work with different backend languages.

andrewingram 11y ago
GraphQL servers exist in multiple languages, many of them have more mature implementations than the reference (JavaScript)server. Sangria (the Scala implementation) is particularly impressive. And one of the Elixir implementations, Absinthe, is coming along very nicely. The main security concerns are: * Data leakage, the GraphQL schema reveals the overall capabilities of your system, which may not be desirable. It may still be necessary to split into private/public implementations. * Denial-of-service. Unless you take steps to mitigate it (there are a few approaches out there), it's often trivial to construct a query that could bring down a server. The two main approaches i've seen are white-listing queries at build time (so clients can't construct arbitrary queries), and adding cost/complexity heuristics to the server and rejecting any query over a certain threshold. * Authentication. Not actually a new concern, because the issue is basically the same as with REST. But you do need to get authentication and permissioning properly designed on the backend, it's not something you can really defer until a later date.