4 ms·
GraphQL is good for some things, but often pretty dangerous for many of the use cases it was originally introduced for. Without aggressive validation, it does i
by languagehacker 8y ago
GraphQL is good for some things, but often pretty dangerous for many of the use cases it was originally introduced for. Without aggressive validation, it does introduce significant blocking and overloading concerns for irresponsible clients or bad actors. I like having a mix of a highly restricted GraphQL API on the read end and a strictly enforced protocol buffer RPC. This enforces good schemas, and encourages extremely slim requests over the wire where possible. It's one very good solution in your toolbelt, and one that integrates really well with a lot of the frontend frameworks out there today. It's just worth being judicious about.
- i_s 8y ago"Aggressive" validation seems to be a part of most libraries for helping people implement GraphQL, so I don't think this is a real issue. I'm assuming you mean stuff like max nodes, max depth, max page size, etc.
- arkadiyt 8y agoIt could also be referencing authentication and authorization controls on fields - I think GraphQL makes it too easy for developers to expose private fields without realizing it. Just last week I found a financial institution exposing bank account numbers and routing numbers (not mine) through their GraphQL endpoint - they still haven't fixed it.
- RussianCow 8y agoThis is just as easy to do with REST, though, and not something unique to GraphQL. Most of the time, the problem has to do with specifying fields to exclude rather than fields to expose, which makes it easy to add a private field to a model and have it automatically, unintentionally exposed by the API.
- cheriot 8y agoWow, someone actually wrote a schema exposing that account number. I've seen that with RESTful endpoints because it's so easy for a developer to serialize an entire object (or object graph) without thinking about what's on it.