4 ms·

Why graohQL vs allowing the frontend to do SQL queries, andnthe backend eventually preprocessing them before asking the DB.

striking 4y ago
GraphQL allows backend teams to retain control on how data is aggregated, and doesn't couple the database schema to the API's representation of the data. The frontend can get exactly what it needs when it needs it, without letting frontend engineers go totally wild and take down the DB (unless the backend engineers let them).
- darkerside 4y ago
  Why not expose a replicated database with read only permissions? On the write side, are people really making use of the flexibility of GraphQL? Because I can't think of a great use case for that, versus just opening up your database. Avoiding coupling the database schema is reasonable, but IME, APIs get stuck in backwards compatibility land and stop making sense anyway. Maybe this is better solved with good views on the read side, and perhaps the write side is open for innovation at the database level?
  - TurningCanadian 4y ago
    Read-only permissions still leave you open to resource exhaustion attacks. On the write side, it's nice to have your query return structured data that can automatically update your client-side cache.
    - darkerside 4y ago
      There seems like a simpler framework hiding in here somewhere. One that can mitigate DOS and mirror your data on the client side.
  - jseban 4y ago
    Yeah and if you really don't want the frontend and backend teams to have to talk to each other, you can let the frontend maintain their own views. The elephant in the room is that backend simply don't have enough work if you let people use javascript and sql to its full potential.
    - shahmeern 4y ago
      Not all clients are written in js (android, iOS). For mobile apps, you’re better off having most logic exist on the backend
      - SemanticStrengh 4y ago
        This is completely solved with Ionic/electron. The smartphones ivory tower will fade with time
        shahmeern 4y ago
        I don’t think solved is the right word. You can build apps using ionic/electron but native apps are objectively better
        SemanticStrengh 4y ago
        > objectively better The myth will keep being repeated for decades
  - shahmeern 4y ago
    Not all APIs are about reading and writing data though. You might want an api to create a db entry but also kick off an async task.
    - darkerside 4y ago
      GraphQL isn't going to buy much of anything there, is it?
    - SemanticStrengh 4y ago
      Although SQL has stored procedures, I agree
ludamad 4y ago
Like people advocating sqlite in busy prod settings, this is squarely "a few rare people swear by this" territory. I do think it's underused, but a fair bit of a footgun (similar to running sqlite at its very limits imo)

striking 4y ago

GraphQL allows backend teams to retain control on how data is aggregated, and doesn't couple the database schema to the API's representation of the data. The frontend can get exactly what it needs when it needs it, without letting frontend engineers go totally wild and take down the DB (unless the backend engineers let them).

darkerside 4y ago
Why not expose a replicated database with read only permissions? On the write side, are people really making use of the flexibility of GraphQL? Because I can't think of a great use case for that, versus just opening up your database. Avoiding coupling the database schema is reasonable, but IME, APIs get stuck in backwards compatibility land and stop making sense anyway. Maybe this is better solved with good views on the read side, and perhaps the write side is open for innovation at the database level?
- TurningCanadian 4y ago
  Read-only permissions still leave you open to resource exhaustion attacks. On the write side, it's nice to have your query return structured data that can automatically update your client-side cache.
  - darkerside 4y ago
    There seems like a simpler framework hiding in here somewhere. One that can mitigate DOS and mirror your data on the client side.
- jseban 4y ago
  Yeah and if you really don't want the frontend and backend teams to have to talk to each other, you can let the frontend maintain their own views. The elephant in the room is that backend simply don't have enough work if you let people use javascript and sql to its full potential.
  - shahmeern 4y ago
    Not all clients are written in js (android, iOS). For mobile apps, you’re better off having most logic exist on the backend
    - SemanticStrengh 4y ago
      This is completely solved with Ionic/electron. The smartphones ivory tower will fade with time
      - shahmeern 4y ago
        I don’t think solved is the right word. You can build apps using ionic/electron but native apps are objectively better
        SemanticStrengh 4y ago
        > objectively better The myth will keep being repeated for decades
- shahmeern 4y ago
  Not all APIs are about reading and writing data though. You might want an api to create a db entry but also kick off an async task.
  - darkerside 4y ago
    GraphQL isn't going to buy much of anything there, is it?
  - SemanticStrengh 4y ago
    Although SQL has stored procedures, I agree

ludamad 4y ago

Like people advocating sqlite in busy prod settings, this is squarely "a few rare people swear by this" territory. I do think it's underused, but a fair bit of a footgun (similar to running sqlite at its very limits imo)