I like a good type system, so I have been maxing out the GraphQL type system, e.g. I have things like,
types in the schema, rather than defensively programming in resolvers.
With typed functional programming, there’s a bit more of a trade off with specifically typing things, because of parametric polymorphism etc.
But for APIs my gut feeling, is the more precise the types the better.
Loose-y goose-y types like
String are good to have around when things are genuinely ambiguous and aesthetically / syntactically pleasing, but that’s about it.
Could you take it too far?
the more precise the types the better.
Particularly at API boundaries, clear data contracts pay off.
Can you encode arbitrary logic in the validations on GraphQL types? Or is it like swagger/json-schema with a fixed set of validations (length, regex, min, max, etc)?
Arbitrary logic to a degree, but you cannot specify types as functions, aka Idris etc…
Which I am fine with. GraphQL’s type system is simple, and that’s a feature imo : )
But it also means some validation logic cannot be represented in the type system.
You are encoding dependent typing into the typing system, this is fantastic for catching bugs and so forth, buuuut it does tend to make more work. If only absinthe actually supported real dependent typing and it was representable in GraphQL. ^.^
But I’m overall a fan of it, I tend to do it as well.
Well I suspect there’s a good reason why dependent typing is still a niche sport.
When reading the Idris book tho (https://www.manning.com/books/type-driven-development-with-idris) it seemed fairly straight forward -
then again, it probably does get rather hairy - you lose type inference etc. (not a problem with Elixir! ; )
Yeah losing type inference is big big, having to type everything becomes a bit irritating… ^.^;
Refined Typing has a couple features of dependent typing (kind of, it just has some more checks over standard HM typing) while still being inferenceable though.