6 ms·

Regarding interfaces, dealing with an in-process, code level interface is just on the surface simpler than dealing with an external interface like a JSON endpoi

Regarding interfaces, dealing with an in-process, code level interface is just on the surface simpler than dealing with an external interface like a JSON endpoint. If you're working with a statically-typed language, the comparison isn't even worth making - a contract that needs to be extensively tested turns into a compile error. Even in a dynamically typed language, the tooling to test that methods are being called correctly are much more mature and developed than determining that two independent services are conforming to the same contract.

ayrx 12y ago
Just wondering out loud: maybe it's possible that tooling for this just hasn't been written yet? Something along the lines of declaratively stating what a JSON endpoint should be like and having a tool automatically assert that the services conform to that interface doesn't look impossible.
- logicchains 12y ago
  F# could do this with type providers. Or, something like Google Protocol Buffers could be used.
  - cs02rm0 12y ago
    Or Java with JAX-RS. Or one of probably hundreds of alternatives.
- jacques_chester 12y ago
  It's been tried many many times, but as a network service you simply have no way to enforce what messages you are going to receive until you receive them. So you have to type check at runtime. You can build tooling to make it easier to produce conforming software at each end, but you can't guarantee that someone won't just go ahead and write any old thing. So in practice you still perform validation on each message. Put another way: distributed systems turn all type errors into runtime errors. The guarantees of compile-time checking are severely weakened.
- aikah 12y ago
  Apache Thrift? the issue is introducing yet another layer of indirection in an application. I'm personally not fan of micro-service architectures that don't use a coherent set of language(s). But the tooling is already here,no question. The issue is,should it be "baked" into a language?
cs02rm0 12y ago
Just because an interface asks for a String parameter doesn't mean you can't send data through it that won't be caught at compile time. Neither does it mean that you can't have an actual Java interface exposed as a JSON endpoint.
- ryanbrunner 12y ago
  By definition, any problems sent to a JSON endpoint necessarily needs to be caught at runtime. You can build up all sorts of defences up to the point of the service boundary, but at some point, something is going to be accepting messages from unknown or little-known services expressed as JSON documents and not a statically-typed interface. That's a pretty fundamental difference in my mind.

ayrx 12y ago

Just wondering out loud: maybe it's possible that tooling for this just hasn't been written yet? Something along the lines of declaratively stating what a JSON endpoint should be like and having a tool automatically assert that the services conform to that interface doesn't look impossible.

logicchains 12y ago
F# could do this with type providers. Or, something like Google Protocol Buffers could be used.
- cs02rm0 12y ago
  Or Java with JAX-RS. Or one of probably hundreds of alternatives.
jacques_chester 12y ago
It's been tried many many times, but as a network service you simply have no way to enforce what messages you are going to receive until you receive them. So you have to type check at runtime. You can build tooling to make it easier to produce conforming software at each end, but you can't guarantee that someone won't just go ahead and write any old thing. So in practice you still perform validation on each message. Put another way: distributed systems turn all type errors into runtime errors. The guarantees of compile-time checking are severely weakened.
aikah 12y ago
Apache Thrift? the issue is introducing yet another layer of indirection in an application. I'm personally not fan of micro-service architectures that don't use a coherent set of language(s). But the tooling is already here,no question. The issue is,should it be "baked" into a language?

cs02rm0 12y ago

Just because an interface asks for a String parameter doesn't mean you can't send data through it that won't be caught at compile time. Neither does it mean that you can't have an actual Java interface exposed as a JSON endpoint.

ryanbrunner 12y ago
By definition, any problems sent to a JSON endpoint necessarily needs to be caught at runtime. You can build up all sorts of defences up to the point of the service boundary, but at some point, something is going to be accepting messages from unknown or little-known services expressed as JSON documents and not a statically-typed interface. That's a pretty fundamental difference in my mind.