If I had to guess, maybe having the same zome on both dnas (to manage consistently the same type of data) and bringing one entry from one dna to the other, and then with that entry you can validate other entries or modify the behaviour as needed?
Heh, yup- see lib_origin and lib_destination in REA Fulfillment’s implementation. Compound remote indexes end up essentially being about entry replication.
Not too many cross-dependencies, except where they are expected. It’s been extremely clean, honestly. I’m very happy with where it’s ended up.
Developer security, as in “type safety” and so on? I’d like to know how you are protecting this more with GraphQl on your side
Pretty much. It goes a bit beyond type safety into type bindings across the serialization membrane, and good error handling support in tests & development code. Also a bit of code generation.
We’ll run through it all in the code deep dive in a couple of days but there’s lots of good stuff. I’d be surprised if you could replicate in the frontend without something like decoders and Flow’s runtime type checking. I also get to leverage some code generation stuff to lessen development overhead.
it’s always good to challenge your infrastructure with edge cases to see if it holds
, how is that going for you?
Kinda… awkwardly better than expected? In that I had case studies for particular types of customisation lined up, and then it’s mostly turned out that those customisations aren’t necessary so we don’t get to build any examples yet lol