3 ms·

> There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually

> There might be some queries expressible in your GraphQL that would have severe performance problems or even bugs, sure, but if your frontend doesn't actually make queries like that, who cares? People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries

lmm 1y ago
> People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries Depends how your system is set up. I'm used to only allowing compiled queries on production instances, in which case attackers have no way of running a different query that you don't actually use.
- buzzerbetrayed 1y ago
  So un-graphql-ing your graphql. This shit is wild.
  - lmm 1y ago
    Shrug, databases have been doing the same thing since the 1970s (and consider also e.g. regexes). Turns out a flexible, expressive language for writing queries isn't always the most secure or performant thing to use as your wire format.
    - yawaramin 1y ago
      That's the exact argument against exposing GraphQL to the frontend.
      - lmm 1y ago
        See https://news.ycombinator.com/item?id=43885465 https://news.ycombinator.com/item?id=43885465
- solatic 1y ago
  Do you understand that decompilers and reverse engineering are a thing? Adversaries are not restricted to using your system the way you designed your system. GraphQL queries are trivial to pull out of Wireshark and other sniffers. If you deliver it to the browser, any determined-enough adversary will have it, period. I wouldn't be surprised in the least if it is already a thing for LLM models to sniff GraphQL endpoints in the quest for ever more data.
  - lmm 1y ago
    > Do you understand that decompilers and reverse engineering are a thing? Do you understand how compiled queries in GraphQL (or even an old-school RDBMS) work? All that gets sent over the wire is the query id. There's physically no way to make the server execute a query the author didn't write.
    - solatic 1y ago
      So you threw out all the benefits of GraphQL. Instead of allowing the frontend to determine what it needs, you need to write a new backend endpoint that will return what's needed for that page. This is no different from writing some /rpc/bffe/get-profile-page call, which is much simpler to write and has much better tooling.
      - lmm 1y ago
        No, our backend serves all the queries that the frontend uses, but (in prod) only the queries that the frontend uses - we compile the queries at build time. When we want to add a new query we figure it out in dev (which allows non-compiled queries, but is not accessible for people outside the company), write it in the frontend, and it will be included in the next build of the backend. This is all pretty basic off the shelf functionality. Maybe spend 5 minutes trying to think about how a system might work instead of assuming everyone else is an idiot.
        SpaceNugget 1y ago
        Yea so you have to add the compiled queries to your back-end to be able to get them on prod, which is what you came out swinging against with a somewhat strongly worded to level comment berating people who choose to not use graphql for having to deal with. Exactly what you just described doing is what the parent comment expected you were doing.

lmm 1y ago

> People with bad intentions can make those slow queries happen at high volume with custom tooling, they don’t have to restrict themselves to how the frontend uses the queries Depends how your system is set up. I'm used to only allowing compiled queries on production instances, in which case attackers have no way of running a different query that you don't actually use.

buzzerbetrayed 1y ago
So un-graphql-ing your graphql. This shit is wild.
- lmm 1y ago
  Shrug, databases have been doing the same thing since the 1970s (and consider also e.g. regexes). Turns out a flexible, expressive language for writing queries isn't always the most secure or performant thing to use as your wire format.
  - yawaramin 1y ago
    That's the exact argument against exposing GraphQL to the frontend.
    - lmm 1y ago
      See https://news.ycombinator.com/item?id=43885465 https://news.ycombinator.com/item?id=43885465
solatic 1y ago
Do you understand that decompilers and reverse engineering are a thing? Adversaries are not restricted to using your system the way you designed your system. GraphQL queries are trivial to pull out of Wireshark and other sniffers. If you deliver it to the browser, any determined-enough adversary will have it, period. I wouldn't be surprised in the least if it is already a thing for LLM models to sniff GraphQL endpoints in the quest for ever more data.
- lmm 1y ago
  > Do you understand that decompilers and reverse engineering are a thing? Do you understand how compiled queries in GraphQL (or even an old-school RDBMS) work? All that gets sent over the wire is the query id. There's physically no way to make the server execute a query the author didn't write.
  - solatic 1y ago
    So you threw out all the benefits of GraphQL. Instead of allowing the frontend to determine what it needs, you need to write a new backend endpoint that will return what's needed for that page. This is no different from writing some /rpc/bffe/get-profile-page call, which is much simpler to write and has much better tooling.
    - lmm 1y ago
      No, our backend serves all the queries that the frontend uses, but (in prod) only the queries that the frontend uses - we compile the queries at build time. When we want to add a new query we figure it out in dev (which allows non-compiled queries, but is not accessible for people outside the company), write it in the frontend, and it will be included in the next build of the backend. This is all pretty basic off the shelf functionality. Maybe spend 5 minutes trying to think about how a system might work instead of assuming everyone else is an idiot.
      - SpaceNugget 1y ago
        Yea so you have to add the compiled queries to your back-end to be able to get them on prod, which is what you came out swinging against with a somewhat strongly worded to level comment berating people who choose to not use graphql for having to deal with. Exactly what you just described doing is what the parent comment expected you were doing.