You didn’t yourself make the point, but the article you linked is fairly polemical. It calls out an entire class of BE devs en masse and accuses them not only of not being well-equipped to handle types of FE complexity, but also poorly designing their own systems by insisting so much on validation. I don’t think the article does a great job backing up that argument. This passage seems to be the most direct treatment, and it’s still fairly vague:
The trigger vs memo problem also happens on the back-end, when you have derived collections. Each object of type A must have an associated type B, created on-demand for each A. What happens if you delete an A? Do you delete the B? Do you turn the B into a tombstone? What if the relationship is 1-to-N, do you need to garbage collect?
If you create invisible objects behind the scenes as a user edits, and you never tell them, expect to see a giant mess as a result. It’s crazy how often I’ve heard engineers suggest a user should only be allowed to create something, but then never delete it, as a “solution” to this problem. Everyday undo/redo precludes it. Don’t be ridiculous.
Maybe I’m missing the real point here, but this doesn’t sound like an average BE type problem. If this standard parent-child type relation, then there are plenty of patterns that don’t involve forbidding deletes, baked into most DBs in fact (do cascading deletes count as “garbage collection”?). Maybe it’s caching, which, yes, we are aware can be quite complex. But then I’m not sure how it relates to the issue of “intent” at all, since the user is not involved at that point.
The closest BE issue that comes to mind would be robustness in API design. Of course we want to try preserve the user’s intent as much as possible and even when we end up running into problems it’s good to be able to preserve that intent in the system so we can provide good feedback. But at the end of the day I think modern FE is just really complex with tons of user input being rapidly provided and so obviously validation is less useful and the balance is going to be a lot different compared to a web API.
But then at the end of the article the author seems to imply that internal APIs (BE/FE splits) are themselves a bad, or at least obsolete idea so
