I just can’t. I find the entire concept behind IDLs and code generation abhorrent. Coming from a background in dynamic languages and automated testing, these ideas just seem silly.
The point of IDLs is to provide a stable, exact, portable and succinct definition of an inter-application protocol. In defining the protocol explicitly in a language neutral way, it is easier to ensure conformance and correctness of implementation.
As a side effect, it does make code generation easy, allows one to optionally apply static typing to ensure that messages are always correctly formed, and ensures a _DRY_ approach across the board.
You could just as easily implement poorly defined interfaces using Protobuf or Thrift -- nobody says that you actually have to use an IDL, and the serialization format doesn't require it as long as you keep the messages self-describing. Moreover, a lot of effort has gone into making Protobuf (and even Thrift) as efficient as possible -- yet another serialization format is wholly unnecessary.
Agreed. There's also something else: in a well implemented IDL-based framework, you automatically avoid part of the version compatibility issue.
Imagine that you add fields/services to a class, without breaking the API. As long as you don't change the ids on your definition, clients with code generated for an old version of the class should still be able to call its services, without serialization/deserialization errors.
IDL is best if it can be generated directly from the service code (using appropriate and syntactically valid markers in the service code to specify what to expose) or if the IDL can be used to generate an interface layer for the service which automatically attaches itself to the correct implementation methods.
Otherwise, you've got to maintain the IDL separately from the service implementation, and keep the two in sync manually. That's a pain, and the bigger your service and/or the more people are involved with developing it the worse the pain gets.
I have three concerns about BERT:
1) It looks like every method in your service code is automatically exposed. That could turn into a security problem. I prefer to explicitly indicate which methods to expose.
2) It looks like your function names have to match the function names exposed by the service. That's fine as a default, but could become a problem over time as the service evolves. Sometimes you want to rewrite the guts without breaking API backward compatibility,
3) I'm not sure how complex the RPC part is; HTTP is plenty capable of sending binary requests and returning binary responses on its own.
I just can’t. I find the entire concept behind IDLs and code generation abhorrent. Coming from a background in dynamic languages and automated testing, these ideas just seem silly.
The point of IDLs is to provide a stable, exact, portable and succinct definition of an inter-application protocol. In defining the protocol explicitly in a language neutral way, it is easier to ensure conformance and correctness of implementation.
As a side effect, it does make code generation easy, allows one to optionally apply static typing to ensure that messages are always correctly formed, and ensures a _DRY_ approach across the board.
You could just as easily implement poorly defined interfaces using Protobuf or Thrift -- nobody says that you actually have to use an IDL, and the serialization format doesn't require it as long as you keep the messages self-describing. Moreover, a lot of effort has gone into making Protobuf (and even Thrift) as efficient as possible -- yet another serialization format is wholly unnecessary.
[Edit] Google even outlines one way to implement self-describing messages using the existing protobuf standard in the project documentation: http://code.google.com/apis/protocolbuffers/docs/techniques....
Other methods including simply encoding fields as tuples of (name, value) -- protobuf includes value types in the field encoding.