3 ms·
Yeah I agree with your stance, but not the conclusion. The way that gRPC (and many other systems) handle this is beautiful and the way all APIs should be built:
by 013a 7y ago
Yeah I agree with your stance, but not the conclusion. The way that gRPC (and many other systems) handle this is beautiful and the way all APIs should be built: your API is a specification, not code, so you start with the spec (SDL), then generate the adapters your implementation needs to plug into it.
This helps elevate changes to the API itself; you can easily write automated systems which detect changes to the specific SDL files. Or, the way companies like Namely [1] do it, keep those SDLs inside a separate repo, then publish the adapter libraries on private npm/etc to be consumed by your implementation.
[1] https://medium.com/namely-labs/how-we-build-grpc-services-at-namely-52a3ae9e7c35 https://medium.com/namely-labs/how-we-build-grpc-services-at...
- remote_phone 7y agoThis has been around since the early 90s or previous. ONC-RPCs did this where you define the interface file and it generates the client and server stubs for you. NFS is based on this, as with other services. Conceptually it’s exactly the same, with some underlying differences.
- majewsky 7y agoGoing even further back in history, ASN.1 is also like this. It's a description language for data structures, and there are separate representations that can be derived from them. It's sort of like JSON, JSON Schema and Protobuf in one. TLS certs are encoded in ASN.1 DER, for instance, and LDAP messages are encoded in ASN.1 BER.
- sunir 7y agoI was reading the the OP's question as generating the API from the implementation. Your point about generating the implementation (i.e. a Proxy interface) from the API spec is right on. Thanks for the Namely case study as well. It was timely reading. :)