8 ms·

Everytime my co-worker tries to mention the "Pareto-Principle" (a.k.a. "Please let's not waste time on this, because it's frontend and I don't care about fronte

Everytime my co-worker tries to mention the "Pareto-Principle" (a.k.a. "Please let's not waste time on this, because it's frontend and I don't care about frontend") and "Single Source of Truth" (a.k.a. "let's expose our DB as directly as possible"), my soul barfs.

zachrose 7y ago
I’ve used “single source of truth” to explain what I like about Redux/the Elm Architecture. Yeah it shouldn’t mean anything about access or indirection but it’s still a decent idea, no?
- haggy 7y ago
  Depends on what your designing. If you're working on highly distributed, microservice based backends then single sources of truth can quickly become a serious bottleneck. Check out Event Sourcing if you're not already familiar with it. This is essentially a pattern where each area of your domain maintains its own view of the data it needs through immutable "facts" (events). In this case you could say the source of truth is your persistent event log but that doesn't hold true if you're not using one (not a great idea but hey I'm not here to judge)
  - cuddlecake 7y ago
    Even worse in my case, we are using event sourcing, but the client reads the Eventstore streams indirectly. It's terribly uncomfortable being the only one on a team of 7 who thinks this is terrible.
    - pgwhalen 7y ago
      Can you describe what you mean by indirectly?
      - Nimelrian 7y ago
        Not the person you're responding to, but I was on a team which probably did the same thing. Instead of listening directly to the event store for events you have another non-abstracting layer on top and listen to that. A sensible architecture would have that layer be an abstraction layer for business use cases, so instead of listening to "user-created", "user-edited" and "user-deleted" events and rebuilding the user state in the consumer every time an event is fired, you'd have that layer expose a single user state stream. The rebuilding is handled entirely within the layer. Many people skip that and just re-expose the "primitive" streams of the event store, because they read "don't expose your persistence layer" and skipped the important ", expose the business state layer instead" which usually comes right after that.
      - cuddlecake 7y ago
        By indirectly I mean that we have a WebSocket API that does nothing more than expose the primitive streams. Our frontend client basically reads any stream it needs. And the main problem is, if you have to handle 40+ streams (and that is not even 30% of what's to come), it gets more and more difficult to provide a good user experience. Thankfully, after much discussion we agreed to do it better... Soon ish.
    - cuddlecake 7y ago
      We have an API that lets clients read streams from beginning to end. They do not read the streams directly, but the API is thin enough that one might go "eh, just give them the lib"
all2 7y ago
I always thought single source of truth applied to documentation. It doesn't make sense used in terms of UI or anything beyond "I need info, where do I look?"
- AlexTWithBeard 7y ago
  It can be applied to pretty much anything. In most cases it's quite reasonable (there should be one and only one list of users of the system), but taken to the extreme (there should be only one list of messages your application may ever give to the user) can hinder the development a lot.
  - gmueckl 7y ago
    I think this appliesmostly to persistently stored data. Redundancy in your data model is dangerous because the copies of the data will eventually get out of sync, resulting in weird bugs. No matter how often and how many transformations you expose the data, make sure that it only exists once deep down in your model. On one of my last jobs, I had to convince my teammates repeatedly that this is a good idea. I always showed them how this was simpler and more robust, yet a few weeks later, they were about to commit the same design errors.
- cwilkes 7y ago
  I can see it applying to UI when there’s two screens that display parts of the same information but are different due to caching. That’s maddening to an end user and then they don’t know what one to trust. Sometimes the first one is correct, sometimes the second.

zachrose 7y ago

I’ve used “single source of truth” to explain what I like about Redux/the Elm Architecture. Yeah it shouldn’t mean anything about access or indirection but it’s still a decent idea, no?

haggy 7y ago
Depends on what your designing. If you're working on highly distributed, microservice based backends then single sources of truth can quickly become a serious bottleneck. Check out Event Sourcing if you're not already familiar with it. This is essentially a pattern where each area of your domain maintains its own view of the data it needs through immutable "facts" (events). In this case you could say the source of truth is your persistent event log but that doesn't hold true if you're not using one (not a great idea but hey I'm not here to judge)
- cuddlecake 7y ago
  Even worse in my case, we are using event sourcing, but the client reads the Eventstore streams indirectly. It's terribly uncomfortable being the only one on a team of 7 who thinks this is terrible.
  - pgwhalen 7y ago
    Can you describe what you mean by indirectly?
    - Nimelrian 7y ago
      Not the person you're responding to, but I was on a team which probably did the same thing. Instead of listening directly to the event store for events you have another non-abstracting layer on top and listen to that. A sensible architecture would have that layer be an abstraction layer for business use cases, so instead of listening to "user-created", "user-edited" and "user-deleted" events and rebuilding the user state in the consumer every time an event is fired, you'd have that layer expose a single user state stream. The rebuilding is handled entirely within the layer. Many people skip that and just re-expose the "primitive" streams of the event store, because they read "don't expose your persistence layer" and skipped the important ", expose the business state layer instead" which usually comes right after that.
    - cuddlecake 7y ago
      By indirectly I mean that we have a WebSocket API that does nothing more than expose the primitive streams. Our frontend client basically reads any stream it needs. And the main problem is, if you have to handle 40+ streams (and that is not even 30% of what's to come), it gets more and more difficult to provide a good user experience. Thankfully, after much discussion we agreed to do it better... Soon ish.
  - cuddlecake 7y ago
    We have an API that lets clients read streams from beginning to end. They do not read the streams directly, but the API is thin enough that one might go "eh, just give them the lib"

all2 7y ago

I always thought single source of truth applied to documentation. It doesn't make sense used in terms of UI or anything beyond "I need info, where do I look?"

AlexTWithBeard 7y ago
It can be applied to pretty much anything. In most cases it's quite reasonable (there should be one and only one list of users of the system), but taken to the extreme (there should be only one list of messages your application may ever give to the user) can hinder the development a lot.
- gmueckl 7y ago
  I think this appliesmostly to persistently stored data. Redundancy in your data model is dangerous because the copies of the data will eventually get out of sync, resulting in weird bugs. No matter how often and how many transformations you expose the data, make sure that it only exists once deep down in your model. On one of my last jobs, I had to convince my teammates repeatedly that this is a good idea. I always showed them how this was simpler and more robust, yet a few weeks later, they were about to commit the same design errors.
cwilkes 7y ago
I can see it applying to UI when there’s two screens that display parts of the same information but are different due to caching. That’s maddening to an end user and then they don’t know what one to trust. Sometimes the first one is correct, sometimes the second.