Cart
[Home] [By Thread] [By Date] [Recent Entries]
[Bill de hÓra] >Because at any given time code is being written to get 2 endpoints >communicating, not n endpoints. The developers are in a hurry working >under unrealistic deadlines and expectations. So, for any 2 endpoints >and given enough developer stress, an RPC is the right thing (it gets >the network out of the way quickly, so you can pretend you're writing >procedural code in a single thread of execution). Even if you had 3 or 4 >endpoints, you can always decompose the comms into pairs (divide and >conquer as anti-pattern). Then one day you wake up to find you have >_lots_ of pairs making RPC calls and trying to reorder of repurpose some >of them (or heaven forbid, their databases) without breaking something >else somewhere else is extremely difficult; there's too many >permutations and the network is suddenly not the sum of its parts >anymore. You're out of control of the code. Yup. Its point-to-point versus hub. point-to-point is faster for setting up bilateral communications but the number of interconnects is O(n-squared). Hubs require more up-front work - message taxonomies, routing etc. but scale O(n). Sean
|
