I honestly dont see any different between graphql and a REST api, in terms of what data is available where.
if you have data you don't want publicly available, just.....don't include it in the model, and make sure your server implementation doesn't return it.
It is possible I don't understand your comment, I suppose, but I really don't see what is so unique about graphql from a security standpoint.
They tried that, but they failed because they didn't know that it's possible to downcast from an interface.
It's really hard to have that kind of problem in a dumb REST API. `return {"name": record.name}` does what it says with hardly any magic. But if I write `return record` there's a whole extra layer that grabs information out of record, and I have to trust that it only grabs the information I want it to grab.
This is not to say that dumb REST APIs are definitely better. Having to do things manually also introduces risks.
If your return a record it only will have data for the fields that you have implemented. When you are implementing graphql, every resolver has to check if the requesting user has the proper permissions to see anything.
Fields aren’t created automatically by the graphql engine itself. You have to write them yourself, or use another tool that generates them for you at run or compile time.
Also it’s not often said, but you can have fields return a union such as AdminRecods and PublicRecord or Record WithoutPrivateData.
if you have data you don't want publicly available, just.....don't include it in the model, and make sure your server implementation doesn't return it.
It is possible I don't understand your comment, I suppose, but I really don't see what is so unique about graphql from a security standpoint.