Initial draft of design thinking (express version)! #158
Conversation
We previously had some antipatterns in that document, but they were kinda weak -- only one or two items. I've expanded the list. Reason: to support the express design document's meta-question "Is Holochain actually the right framework for your app?"
It's not so express... it's kinda big
plus glossary amendments to support content
|
@dhtnetwork RFR; I've pared it down substantially and I think it sorta works. Will try to get a staging sit setup for you to look at. Changes:
Outstanding question: I don't feel like it makes sense to talk about designing the app's modules until after membranes and entries/links are designed, because you don't know how to break things up until you've decided what to break up and why you should break them up. I'm also considering moving 'membranes' after 'entries/links', because designers will probably have a better idea of what should be protected with membranes after that step. That makes me wonder about validation rules too, cuz they should def be coupled with entries/links/membranes. Probably put modularity after all that. But now I'm not sure... something worth debating with Art, I think. I'll leave it as-is for now. My big goal is to make this a really good, useful design guide that will reduce backtracking on account of an inefficiently laid out process. I'm okay with backtracking, because it's part of the iterative process, but it should be purposeful, not wasteful. |
* Removed redundant information about init function * mentioned progenitor vs subsequent users in guide and glossary
What is meant by “true real-time performance” here? Chat for instance is often referred to as a “real-time” medium that’s dependent on decent latency, but I’m guessing it’s not defined as such here since chat is an oft-touted use case for Holochain. Real-time networked games are probably a no-go. What about video conferencing? Also there’s overlap in the “not ideal if” here and the When NOT to use Holochain topic. They should at the very least be interlinked, but ideally one should just supplant the other entirely. |
|
Good critique @erlend-sh , and I'm grateful you took the time to poke at this PR. 'true real-time performance' is indeed mushy language, and it probably could be tightened up. In my definition video streaming and action-type games wouldn't make the cut, but chat and collaborative editing would. How about "You need extremely low latency and high throughput" and then continue with the rest of the bullet? |
By "real-time performance" I refer to carefully timed action/reaction needs such as in multi-player first-person shooter games. In an eventually consistent network different players could get information in slightly different orders or with noteworthy delay. Within the span of a 5 second delay, I can shoot you 10 times before you even see me. A 5 second delay in the arrival of a chat message does not cripple the ability to use a chat app. I don't even think Paul's examples or proposed clarification are quite on target. One way video streaming / live-casting is feasible on holochain, because a 30 second delay in a live-stream still within the constraints of being considered effective live-streaming, even though it is a high bandwidth. You also get low-latency for chat by direct message notification for users who currently have that chat channel open. Their UI could update immediately instead of needing to wait for discovery of links. That's just what lets us get the behavior down to a few seconds, which I still would not consider "real-time." Don't try doing remote surgery via a interface with a few seconds lag -- very dangerous. Note: For something like "real-time" video conferencing, you could use Holochain to establish a WebRTC connection between peers, but the audio/video would not be propagating through Holochain before being seen by your counterparty. If you want to record the call, you could have commits and DHT propagation trailing behind the call (like in the live-streaming case above). |
Frankly for newbie hApp dev, I don't think the modules conversation is very important at all. I give it a brief mention so the people can keep it in mind, but I don't expect an early decision to be a final decision. People regularly reorganize their code as the code unfolds, that's just why it's worth a mention, but not spending too much time on it.
Understanding what things need to be in completely different DNA/DHTs for privacy or participation membranes seems to be a fundamental first step. Because it means creating different DNAs altogether. It is my experience that when people have an idea about something they want to build, they already have a high level view of privacy and security issues to shape this decision. If you make this decision later in the process, then you've designed all your app/validation logic under a false set of assumptions that things are unified in a single DNA/DHT that are in fact not unified, and you then have to go back and refactor everything with the understanding that you'd have be making bridge calls between things, blah, blah, blah... The membranes decision shapes everything else, which is why I do it first with people.
The thing about validation rules, is that although they are the HEART of data integrity/security/permissions, you actually can get things running without them. My observation is (especially if you're doing test driven development) that having no validation (just return Ok() ) makes it possible to get early tests passing and data flowing which helps people understand what's happening so that validation rules can actually be written better once they understand the flows that are happening by getting their tests to pass.
There... that was my part of the debate. :) |
I would love to try the inline PR review/suggest process with this one.
Also, I really did try to make it an 'express' version, but there was just so much important stuff to write...