Hacker News Reader

Comment by ryanbrunner | Hacker News Reader

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.

View on HN

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.

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.

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.

F# could do this with type providers. Or, something like Google Protocol Buffers could be used.

Or Java with JAX-RS. Or one of probably hundreds of alternatives.

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.

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?

Reply on news.ycombinator.com