4 ms·

Generated interfaces are an anti-pattern. Types force tight coupling between clients and servers. What if a third-party project written in a different language

Generated interfaces are an anti-pattern. Types force tight coupling between clients and servers. What if a third-party project written in a different language wants to communicate with your server using their own client? Types will make it more difficult for them to integrate because: 1. If they're using a dynamically typed language, this gives them extra work to typecast everything back and forth whenever they need to communicate with your system. 2. Even if they use types, maybe their type system is not compatible with yours and they need to do a lot of tedious extra work to typecast everything.

zwerdlds 8y ago
what is the solution? runtime errors?
asark 8y ago
Huh? Everything always has a type anyway. It's sometimes just harder to know what it is. Specifying doesn't make the types appear out of nowhere, it just documents them.
true_religion 8y ago
I wouldn't call that an antipattern. I treat other systems like I do the database and enforce consistency at the API level. I wouldn't ask for a database to be totally untyped (and thus silently coerce things into its internal types in reality), so I don't ask for the same in an API. Though, I can understand some people have differing preferences---MongoDB is popular for example---but I wouldn't call it an anti-pattern no matter which choice one makes.
tom_ 8y ago
No, it makes it easier, because they have a specification to work from, and they can probably just use that spec to generate their own glue code, assuming any is necessary. I have never found option 2 to apply in any meaningful fashion, though I'm sure others have done much more of this type of work than I have.
- phamilton 8y ago
  I've found it to be annoying in the other direction. A type system like protobuf isn't rich enough for the problem domain. We end up building a lot of additional validation into the servers and clients that could have been enforced by the service/types spec.
phamilton 8y ago
Which is why our rpc services accept json in addition to protobuf. Yay, problem solved.

zwerdlds 8y ago

what is the solution? runtime errors?

asark 8y ago

Huh? Everything always has a type anyway. It's sometimes just harder to know what it is. Specifying doesn't make the types appear out of nowhere, it just documents them.

true_religion 8y ago

I wouldn't call that an antipattern. I treat other systems like I do the database and enforce consistency at the API level. I wouldn't ask for a database to be totally untyped (and thus silently coerce things into its internal types in reality), so I don't ask for the same in an API. Though, I can understand some people have differing preferences---MongoDB is popular for example---but I wouldn't call it an anti-pattern no matter which choice one makes.

tom_ 8y ago

No, it makes it easier, because they have a specification to work from, and they can probably just use that spec to generate their own glue code, assuming any is necessary. I have never found option 2 to apply in any meaningful fashion, though I'm sure others have done much more of this type of work than I have.

phamilton 8y ago
I've found it to be annoying in the other direction. A type system like protobuf isn't rich enough for the problem domain. We end up building a lot of additional validation into the servers and clients that could have been enforced by the service/types spec.

phamilton 8y ago

Which is why our rpc services accept json in addition to protobuf. Yay, problem solved.