4 ms·
Hi. I'm the author. I'm advocating breaking the system into modules with messaging between them, at a fairly course grain (i.e., between subsystems). Within th
by silentbicycle 14y ago
Hi. I'm the author.
I'm advocating breaking the system into modules with messaging between them, at a fairly course grain (i.e., between subsystems). Within the modules, do whatever you want, but I'm talking about decomposing a system into a service-oriented architecture, or multiple Erlang processes and applications, or Unix pipes, or whatever you want to call it. (Doing it at too fine a grain leads to lots of CPU churn from excess serialization, of course.)
JSON is a decent example of a neutral and lightweight protocol, but it's worth actually thinking long and hard about the shape those messages should take. (I prefer text or binary payloads, but I'm also doing embedded development and a real JSON library costs ROM.) Thinking hard about those interfaces/protocols between the pieces, and keeping them tight, is where the value comes from.
(Kind of a quick response because I'm at Clojure/Conj today, sorry if I'm missing part of your point.)
- look_lookatme 14y agoOK then, I misunderstood the paragraph. I took it to mean that you were enforcing a lowest common denominator type system across all calls, regardless of intra or inter system. EDIT Reading further, I guess it was the JSON bit that threw me off. It seems that you'd want to have brokers at the edge of modules or in between them in this case. That's may seem architechty, but the reality is that you aren't coupling a module to any non native type representation. Objects go in, objects come out.
- silentbicycle 14y agoEach node can have its own type system, when it makes sense to do so. The arcs between them just need to agree on how they communicate.