|
|
|
|
|
by u320
3366 days ago
|
|
What the first chart doesn't show you is how much stuff is going on in the "web app" box. If you have e.g. a User entity, you would have to add code to write to the 3 secondary datastores at each point they are written to. And if you add another one, you have to go back and find every write and modify it. In the second example you handle it once per entity and datastore and the "web app" doesn't need to be aware of the secondary stores. It's just the listener pattern applied at infra level. You trade code complexity for infra complexity. |
|
That is much easier to track, trace, understand, and debug than a request that flows through 7 servers, 5 data layers (that have their own configs, nuances, snafus, caveats, etc.), and 2 proxies, each of which introduces a point of potential corruption/breakage, before it finally reaches the place it's trying to go.
Anyway, like I said in the grandparent, I'm sure there are times when this is the best way to accomplish something. It's hard to nitpick an unfortunately-potentially-appropriate specific solution in the general sense, except to say that its potential applicability is unfortunate.
The problem is that people do not see such complexity for the unfortunate byproduct of poor technical and/or organizational architecture that it is, but rather as evidence of their own expertise. That is exactly backwards. We must fix that false impression to restore sanity to the profession.