3 ms·

> with type safety GraphQL provides one-way (server-bound) run-time type assertions. I constantly see developers that should know better confuse validation wi

> with type safety GraphQL provides one-way (server-bound) run-time type assertions. I constantly see developers that should know better confuse validation with type checking. I've had developers, in earnest, ask how they can use TypeScript on run-time data inputs. I have to break the bad news to them and simply tell them: no, you can't do that. That's not how type systems work. Out of the box, GraphQL provides no validation, that I know of, beyond the elementary data types. Anyone that knows a thing about XSS or SQL-injection can tell you that a string is not always just a string. Anyone using C/C++ that has dealt with stack overflows and code injection can tell you that an integer is not always an integer. Sometimes it's a pointer. Oops. You're going to hand code validations, each and every time. Because no tool knows how many characters your DB is setup to handle for a username, for example. GraphQL and TypeScript won't save you.

tshaddox 6y ago
I understand the distinction you're making, but I think it's fuzzier than you seem to think. Yes, GraphQL responses tend to go over the wire in a format without any type checking (like JSON). But GraphQL tooling and libraries can use GraphQL schemas to ensure that application code that consumes GraphQL responses will never see a value with a type that contradicts the GraphQL schema. GraphQL tooling cannot literally prevent JSON from having a string value where there's supposed to be a number value, but it can ensure that application code never has runtime type errors. Is that "validation rather than type checking"? Sure, I suppose so, but my application code that consumes GraphQL responses will either get some representation of an error, or a representation of a successful response that is guaranteed to have the types I expect. And yes, there are plenty of other data formats and tools that provide the same sort of thing: some representation of a schema, some non-application code that checks runtime data against that schema, and a contract with the application code that each response will be either an error or a type-safe successful response.

tshaddox 6y ago

I understand the distinction you're making, but I think it's fuzzier than you seem to think. Yes, GraphQL responses tend to go over the wire in a format without any type checking (like JSON). But GraphQL tooling and libraries can use GraphQL schemas to ensure that application code that consumes GraphQL responses will never see a value with a type that contradicts the GraphQL schema. GraphQL tooling cannot literally prevent JSON from having a string value where there's supposed to be a number value, but it can ensure that application code never has runtime type errors. Is that "validation rather than type checking"? Sure, I suppose so, but my application code that consumes GraphQL responses will either get some representation of an error, or a representation of a successful response that is guaranteed to have the types I expect. And yes, there are plenty of other data formats and tools that provide the same sort of thing: some representation of a schema, some non-application code that checks runtime data against that schema, and a contract with the application code that each response will be either an error or a type-safe successful response.