Closed gotjoshua closed 6 years ago
I don't have the knowledge to fully understand this diagram, but I think you got it right.
The usecases of ObjectModel I saw previously are:
I think there may have interesting things to do with Meteor and ObjectModel. I never used Meteor myself so I won't be very helpful, but as I understand it, with Meteor some of the code is shared between server and client, so in theory you can do both server-side and client-side validation. I don't know if this is possible and/or useful.
I must say, I am really enjoying to rely on ObjectModel with Meteor.
The shared code is great . We are using shared Object Model definitions for entity types, using instances to populate test data, and casting/validating on the thresholds (JSON exchanges with the CiviAPI and untyped JS objects with the Mongo Collections).
Thanks again for your engagement and for the great library!
Good, then this is a great usecase for this library indeed. I'm glad you figured this out, because dynamic type-checking can be hard to sell.
I have nothing more to say, I think you're already doing a great job. Thanks for sharing your case !
So as you said you "love to know how everyone uses my work and how can we improve it further"...
I'd like to ask you for a conceptual review of our data flow model:![OMap App Layer Model](https://docs.google.com/drawings/d/e/2PACX-1vTQ0rSDCDAgX8uyGzfMeFPFtt9dE4-PR5x49Hyq6IIdKXQreQiOjZ0ig6U7ZQzUEN3TSMl_3GvIUOZa/pub?w=962&h=1042)
Basically we tried to take your advice to use "Models at your API boundaries to validate user input, network responses or serialized data.".
We have data coming from two different sources (so far), one of them with Server Push (Meteor Mongo) - both sending serialized JSON over the wire. Therefore creating ObjectModels for all our entities and Dynamically Typed Maps feels like a great way to distribute the data down the container/page/component tree.
I'm curious about your thoughts to the diagram and the approach...