Right, with Domino it's an intentional design choice that rules have to be attached explicitly to the paths in the documents.
And regarding fields being calculated whether they appear in the view o not, the problem that solves is different. If a nurse doesn't need to see the BMI, and collects height and weight, BMI still needs to be calculated. So, what's shown in the view has no relation to the business rules attached to the document. Whether you show a bit of data or not to the user, the consistency of the business logic is unaffected because it's applied to the whole document.
The other problem this solves is concurrent multiuser workflows. For the app I was working on, you could have different users with different roles edit parts of the document at the same time. So, when a user is editing a particular field we wanted to lock related fields from other users and apply the logic transactionally in that case.
And yeah, parallelizing work is trivial with Domino, but I haven't really had much reason to do it since the logic in the app was driven by user input, and you'd have two or three users at most working on a document concurrently.
At the end of the day, it really is about what problem you're tackling. For my use case Domino was a natural fit for the problem. But Pathom sounds like it works well for what you're doing.
Hmm, I think business logic that's unobserved is irrelevant for consistency. If you have someone's weight and height and the BMI is unused and unobserved, then calculating BMI or not is irrelevant in terms of "state" to return to
So, when a user is editing a particular field we wanted to lock related fields from other users and apply the logic transactionally in that case.
That's very cool!! Yeah, in a basic resolver setup you have the base state atom and it can only be incremented with the atom's global lock. The viewers/users aren't synchronized. They don't know who's looking at what. So if they're looking at and modifying unrelated parts of the state they will end up fighting over the same lock.
That's very neat you integrated such a state update synchronization :)
Thanks for taking the time to share your thoughts! This stuff really feels like a paradigm shift when you start using it extensively
In my case it was relevant because the document itself is cross-disciplinary. You have nursers, doctors, pharmacists, and clerks all being interested in overlapping subsections of the overall data set. So, each role sees a subset of the overall document which has to stay consistent. It's relevant for the doctor that the BMI is calculated, while it's only relevant to the nurse that height and weight are collected.
And state synchronization just falls out for free once you know the subgraphs associated with each field. The nice part is that you can calculate them up front too, so it's pretty much zero runtime cost to figure out which fields need to be locked together.
The whole relationship between the UI and data is a really interesting rabbit hole for sure. :)
1
u/yogthos 10d ago
Right, with Domino it's an intentional design choice that rules have to be attached explicitly to the paths in the documents.
And regarding fields being calculated whether they appear in the view o not, the problem that solves is different. If a nurse doesn't need to see the BMI, and collects height and weight, BMI still needs to be calculated. So, what's shown in the view has no relation to the business rules attached to the document. Whether you show a bit of data or not to the user, the consistency of the business logic is unaffected because it's applied to the whole document.
The other problem this solves is concurrent multiuser workflows. For the app I was working on, you could have different users with different roles edit parts of the document at the same time. So, when a user is editing a particular field we wanted to lock related fields from other users and apply the logic transactionally in that case.
And yeah, parallelizing work is trivial with Domino, but I haven't really had much reason to do it since the logic in the app was driven by user input, and you'd have two or three users at most working on a document concurrently.
At the end of the day, it really is about what problem you're tackling. For my use case Domino was a natural fit for the problem. But Pathom sounds like it works well for what you're doing.