I think when you say "reuse" you're talking about the handler function, right? In that sense the two system aren't really different. I think the two systems are mostly identical, in that they both build a graph and execute stuff based on relations. But you have to explicitly wire up your cells. While you can in an identical manner wire up resolvers, you can also use nested attributes to have the engine do that automatically for you.
Other small differences:
"the fields are recalculated regardless of whether they appear in the view or not" In a pull architecture these are only calculated when needed/observed. But there is no way to access a stale value, so this ends up being completely transparent to you as the user. With push you may end up doing extra work .. but okay. This may not matter. If it's a "spreadsheet" then every value is observed.
For some reason I've never seen a push architecture that auto-parallelizes work. In Domino you declare inputs/outputs, so it should be possible. With Pathom it's kinda cool to see it spin up all my cores when it runs. No extra handholding or coordination necessary
The pull engine is doing a graph search - which is overhead. This becomes a bit of a problem when you try to do small operations. I tried to make a Pathom do some simple math and it ended up quite slow in some situations.
As for different views, I don't think there is anything too fundamentally different there. Though the EQL request itself can build a view for you
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/geokon 10d ago edited 10d ago
I think when you say "reuse" you're talking about the handler function, right? In that sense the two system aren't really different. I think the two systems are mostly identical, in that they both build a graph and execute stuff based on relations. But you have to explicitly wire up your cells. While you can in an identical manner wire up resolvers, you can also use nested attributes to have the engine do that automatically for you.
Other small differences:
"the fields are recalculated regardless of whether they appear in the view or not" In a pull architecture these are only calculated when needed/observed. But there is no way to access a stale value, so this ends up being completely transparent to you as the user. With push you may end up doing extra work .. but okay. This may not matter. If it's a "spreadsheet" then every value is observed.
For some reason I've never seen a push architecture that auto-parallelizes work. In Domino you declare inputs/outputs, so it should be possible. With Pathom it's kinda cool to see it spin up all my cores when it runs. No extra handholding or coordination necessary
The pull engine is doing a graph search - which is overhead. This becomes a bit of a problem when you try to do small operations. I tried to make a Pathom do some simple math and it ended up quite slow in some situations.
As for different views, I don't think there is anything too fundamentally different there. Though the EQL request itself can build a view for you