7 ms·

> I never understood why people go for graphql. It allows a full separation of the frontend dev velocity from the backend velocity. The frontend is no longer

by buro9 3y ago

> I never understood why people go for graphql. It allows a full separation of the frontend dev velocity from the backend velocity. The frontend is no longer dependant on backend engineers for API creation, nor negotiations on how those should look. The backend can choose to observe the hot path of GraphQL and optimise those for your #3, but #1 and #2 don't differ from, say, REST.

x86x87 3y ago
So you're solving an organizational problem by using gql? Who needs proper authz/authn, security, scalability, sanity, qos if we can have frontend dev velocity? Checks out.
- seanp2k2 3y ago
  GraphQL really needs a gateway like Envoy to give better observability / control / auth, and indeed that’s how lots of people deploy it.
  - x86x87 3y ago
    Okay. Tell me how you do the control/auth and allow certain users to access a resource while others do not access it while they may formulate complex queries where they ask for the kitchen sink.
    - andrewingram 3y ago
      By wrapping the code that loads data with code that checks whether the current (i.e. requesting) user is allowed to load that data. I don't really understand the problem, how is this any more difficult than any other API paradigm?
      - foota 3y ago
        I think the additional issues come when you want to define access by a relationship instead of just the entity, which means you need to check access based on the edges, and not the nodes. You'd have to do this anyway with REST, but I think it's easier in some ways to make mistakes and allow more access than intended.
    - pravus 3y ago
      I honestly don't understand the complaints here. In our deployment it's implemented as an HTTP handler right next to all the REST ones and gets all of the standard authz/authn/obervability wrappers. It's allowed us to focus more on core development because the schema was exported over a year ago and hasn't changed much. It functions almost identically to the REST components but is easier to develop against. No issues with scale or performance that aren't apparent in the REST components either.
    - tomtheelder 3y ago
      Honestly there’s a few good ways to do that. Schema directives, regular old permission system at the resolver level, etc. I’m not a big fan of GraphQL, but I it’s not particularly difficult to secure.
    - seanp2k2 3y ago
      https://konghq.com/blog/engineering/graphql-authorization-at-the-api-gateway-with-kong-konnect-and-opa https://konghq.com/blog/engineering/graphql-authorization-at... has a pretty comprehensive look into one way to handle auth with Kong. I believe Envoy can do something similar. It’s not as easy as an htaccess with regex on routes but it’s not impossible.
    - ewalk153 3y ago
      This is handled at the library level, typically. For example in graphql-ruby, it’s built in [1] [1] https://graphql-ruby.org/authorization/visibility.html https://graphql-ruby.org/authorization/visibility.html
    - deecewan 3y ago
      > Tell me how you do the control/auth and allow certain users to access a resource while others how would you do this with REST? or any other kind of API? graphql, at it's core, is a tool for the frontend to describe to the backend what data it wants. how the backend replies to that is completely up to the backend. > formulate complex queries where they ask for the kitchen sink most concrete implementations i've seen include a way to limit complexity. in `graphql-ruby` for example, you can limit how many nodes, and you can apply a "cost" to a particularly expensive-to-calculate node if you like. Say you give an API only 10 "complexity points". You could make most nodes cost 1 point, and expensive nodes cost 3 points. Now, someone can _request_ the kitchen sink, but you can respond with a "no".
  - politelemon 3y ago
    Is it not possible without Envoy? IMO this feels like a failing if I'm relying on a separate piece of software. I'm comparing it with RESTish services which are easily scaleable in many ways either software or infra. But that might be my misunderstanding of what you just said
    - seanp2k2 3y ago
      It’s something that’s handled a lot these days at BigCos by service / query gateways / proxies and in the places that utilize these heavily it’s pretty automated from my experience. Basically the dev experience is you go into some web ui or make a PR against some JSON / yaml policy to allow whatever then it just works because some other sec / infra team plumed in all the auth and access control parts. GQL itself doesn’t attempt to solve authZ or authN by design. Edit: if you want to do this with nginx or within graphql / express, this is what that could look like https://www.apollographql.com/blog/backend/auth/a-guide-to-authentication-in-graphql/ https://www.apollographql.com/blog/backend/auth/a-guide-to-a...
- pests 3y ago
  Don't we solve organizational problems with software all the time? Git Monorepo vs Polyrepo Microservices vs Monolith Kubernetes
  - caseyohara 3y ago
    Reminds me of Conway's Law, which states that the structure of your systems will mirror the structure of your organization. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
    - dboreham 3y ago
      See also: Reverse Conway.
- dasil003 3y ago
  > So you're solving an organizational problem by using gql? Yes, of course! All problems are organizational problems at scale. I have no great love for gql, but painting it as a black and white decision pitting FE velocity against all other engineering concerns (including hyperbole like "sanity") is childish. There are legit tradeoffs discussions to be had, but if you think it's impossible to secure or scale gql then you're not a very imaginative or resourceful engineer.
- eddythompson80 3y ago
  Solving organizational problems is a core component of any software you design in any organization that's not a 100% flat startup unfortunately. > "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." - Melvin E. Conway It's unavoidable. You can bury your head in the sand about it and demand that the technical structure only match your technical requirement, but then the organizational structure of the company will grind to a hault. People will always be people. Just because you give some of them a title like "Engineer" doesn't mean that we won't conflict on people problems. Entire concepts like event driven architectures or microservices, while might have plethora of technical pros/cons are mainly pushed by management for their non-technical aspects. One of their main non-technical pro is organizational. If your component just emits events, handles events, and is implemented as a separate microservice then you can always just insert a team, or move a team in an organizational structure while minimizing the overall impact to a project.
  - deleted 3y ago
    [deleted]
- chrischen 3y ago
  The simplest way to add auth is to read a user session and provide it in the context, and then do the logic in the resolver for access control. It's not any different from how you would do it in a regular REST based server and GraphQL certainly doesn't do anything specific to get in your way about it. Not sure why people keep bringing auth and scalability into it. Clearly facebook invented and uses it for the purpose of auth and scalability.
physicsguy 3y ago
Except when it’s not performant, and then suddenly you need those backend guys again!
- satvikpendem 3y ago
  If GraphQL is set up correctly ie through Apollo Server or other server implementations which implement performance optimizations, backend people will never have to touch it again, yes.
  - physicsguy 3y ago
    “No true Scotsman” fallacy surely? Yes, in theory, but in practice, all sorts of issues like the N+1 problem can pop up
jameshart 3y ago
> frontend is no longer dependant on backend engineers for API creation So long as the backend engineers at least anticipated all the relationships, properties and objects that the frontend might ever need?
brabel 3y ago
What? And who is writing and implementing the GraphQL schema?? I work on a GraphQL backend and I can tell you, every time the UI needs some new fields we don't have in the GraphQL schema, I've gotta go and implement that just like in REST, the fields don't magically materialize into existence.

by buro9 3y ago

x86x87 3y ago

So you're solving an organizational problem by using gql? Who needs proper authz/authn, security, scalability, sanity, qos if we can have frontend dev velocity? Checks out.

seanp2k2 3y ago
GraphQL really needs a gateway like Envoy to give better observability / control / auth, and indeed that’s how lots of people deploy it.
- x86x87 3y ago
  Okay. Tell me how you do the control/auth and allow certain users to access a resource while others do not access it while they may formulate complex queries where they ask for the kitchen sink.
  - andrewingram 3y ago
    By wrapping the code that loads data with code that checks whether the current (i.e. requesting) user is allowed to load that data. I don't really understand the problem, how is this any more difficult than any other API paradigm?
    - foota 3y ago
      I think the additional issues come when you want to define access by a relationship instead of just the entity, which means you need to check access based on the edges, and not the nodes. You'd have to do this anyway with REST, but I think it's easier in some ways to make mistakes and allow more access than intended.
  - pravus 3y ago
    I honestly don't understand the complaints here. In our deployment it's implemented as an HTTP handler right next to all the REST ones and gets all of the standard authz/authn/obervability wrappers. It's allowed us to focus more on core development because the schema was exported over a year ago and hasn't changed much. It functions almost identically to the REST components but is easier to develop against. No issues with scale or performance that aren't apparent in the REST components either.
  - tomtheelder 3y ago
    Honestly there’s a few good ways to do that. Schema directives, regular old permission system at the resolver level, etc. I’m not a big fan of GraphQL, but I it’s not particularly difficult to secure.
  - seanp2k2 3y ago
    https://konghq.com/blog/engineering/graphql-authorization-at-the-api-gateway-with-kong-konnect-and-opa https://konghq.com/blog/engineering/graphql-authorization-at... has a pretty comprehensive look into one way to handle auth with Kong. I believe Envoy can do something similar. It’s not as easy as an htaccess with regex on routes but it’s not impossible.
  - ewalk153 3y ago
    This is handled at the library level, typically. For example in graphql-ruby, it’s built in [1] [1] https://graphql-ruby.org/authorization/visibility.html https://graphql-ruby.org/authorization/visibility.html
  - deecewan 3y ago
    > Tell me how you do the control/auth and allow certain users to access a resource while others how would you do this with REST? or any other kind of API? graphql, at it's core, is a tool for the frontend to describe to the backend what data it wants. how the backend replies to that is completely up to the backend. > formulate complex queries where they ask for the kitchen sink most concrete implementations i've seen include a way to limit complexity. in `graphql-ruby` for example, you can limit how many nodes, and you can apply a "cost" to a particularly expensive-to-calculate node if you like. Say you give an API only 10 "complexity points". You could make most nodes cost 1 point, and expensive nodes cost 3 points. Now, someone can _request_ the kitchen sink, but you can respond with a "no".
- politelemon 3y ago
  Is it not possible without Envoy? IMO this feels like a failing if I'm relying on a separate piece of software. I'm comparing it with RESTish services which are easily scaleable in many ways either software or infra. But that might be my misunderstanding of what you just said
  - seanp2k2 3y ago
    It’s something that’s handled a lot these days at BigCos by service / query gateways / proxies and in the places that utilize these heavily it’s pretty automated from my experience. Basically the dev experience is you go into some web ui or make a PR against some JSON / yaml policy to allow whatever then it just works because some other sec / infra team plumed in all the auth and access control parts. GQL itself doesn’t attempt to solve authZ or authN by design. Edit: if you want to do this with nginx or within graphql / express, this is what that could look like https://www.apollographql.com/blog/backend/auth/a-guide-to-authentication-in-graphql/ https://www.apollographql.com/blog/backend/auth/a-guide-to-a...
pests 3y ago
Don't we solve organizational problems with software all the time? Git Monorepo vs Polyrepo Microservices vs Monolith Kubernetes
- caseyohara 3y ago
  Reminds me of Conway's Law, which states that the structure of your systems will mirror the structure of your organization. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
  - dboreham 3y ago
    See also: Reverse Conway.
dasil003 3y ago
> So you're solving an organizational problem by using gql? Yes, of course! All problems are organizational problems at scale. I have no great love for gql, but painting it as a black and white decision pitting FE velocity against all other engineering concerns (including hyperbole like "sanity") is childish. There are legit tradeoffs discussions to be had, but if you think it's impossible to secure or scale gql then you're not a very imaginative or resourceful engineer.
eddythompson80 3y ago
Solving organizational problems is a core component of any software you design in any organization that's not a 100% flat startup unfortunately. > "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." - Melvin E. Conway It's unavoidable. You can bury your head in the sand about it and demand that the technical structure only match your technical requirement, but then the organizational structure of the company will grind to a hault. People will always be people. Just because you give some of them a title like "Engineer" doesn't mean that we won't conflict on people problems. Entire concepts like event driven architectures or microservices, while might have plethora of technical pros/cons are mainly pushed by management for their non-technical aspects. One of their main non-technical pro is organizational. If your component just emits events, handles events, and is implemented as a separate microservice then you can always just insert a team, or move a team in an organizational structure while minimizing the overall impact to a project.
- deleted 3y ago
  [deleted]
chrischen 3y ago
The simplest way to add auth is to read a user session and provide it in the context, and then do the logic in the resolver for access control. It's not any different from how you would do it in a regular REST based server and GraphQL certainly doesn't do anything specific to get in your way about it. Not sure why people keep bringing auth and scalability into it. Clearly facebook invented and uses it for the purpose of auth and scalability.

physicsguy 3y ago

Except when it’s not performant, and then suddenly you need those backend guys again!

satvikpendem 3y ago
If GraphQL is set up correctly ie through Apollo Server or other server implementations which implement performance optimizations, backend people will never have to touch it again, yes.
- physicsguy 3y ago
  “No true Scotsman” fallacy surely? Yes, in theory, but in practice, all sorts of issues like the N+1 problem can pop up

jameshart 3y ago

> frontend is no longer dependant on backend engineers for API creation So long as the backend engineers at least anticipated all the relationships, properties and objects that the frontend might ever need?

brabel 3y ago

What? And who is writing and implementing the GraphQL schema?? I work on a GraphQL backend and I can tell you, every time the UI needs some new fields we don't have in the GraphQL schema, I've gotta go and implement that just like in REST, the fields don't magically materialize into existence.