App Design Decisions

--- tags: v3 --- # App Design Decisions Note: Here's a list of questions that we need answers to in order to build an app. It would be unrealistic that we come up with answers to everything here in one sitting. In situations where, after we've debated the merits of different approaches, we're still stumped, we should leave it unresolved and do some research. Phone a friend. Take a field trip to another app and see how they do it. ## Post Mortem ### What we like about the app ### What sucks about the app ### What needs to change ### What should stay the same ### What new demands do we forsee on these next apps? ## Architecture ### What parts of the app should be DAOTools What parts of the app should the dev be able to change? What parts of the app should be 'locked' in a node module? UI Data ### Should we build DAOTools first, then the app? Or should we extract them from a new app? We will separate the UI component library and the data library above from the beginning. Dev flow might dictate working within app repo at times and then moveing out to libraries. ### How are we going to handle DAO config? Data library will handle graph data fetching, backend stored data fetching, and transforming into a single data structure to pass into apps. ### Will data packages also wrap moloch/baal contracts? - https://github.com/raid-guild/quiver/tree/main/web3/hooks - our txLegos handle this. ### How do we maintain DAOtool repos? - methodology for answering decentralized vs. custom/hosted solution TODO: Define methodology ### If we're rebuilding V2, and our new style will be 'App of apps', could we seemlessly link betweev V2 DAOs and V3 DAOs? Yes. - consider v3 data model as we work through that. ### How do we divide the app into smaller apps? Where do we cut? https://www.figma.com/file/nUYTYBvb2ARZUvrnSMP4KG/Strategic-Directions?node-id=0%3A1 TODO: Finalize what is in each app and when/how we'll work on them. This is dependent on UI/UX design as well ### What needs to go to a backend caching service? - How can we support TX legos and other legos while not loading 30,000 proposals on page load? - can we push more to the subgraph to support paginated graph fetching? - enhancing caching? TODO: - Define how/if we want to store LEGOs outside of the app - in a package or in a decentralized datastore? - Further define DAO config and architecture for that ### What legos (if any) should stay on the app vs. stored in IPFS? - see above ### How can we handle multiple decentralized storage options? - Function code (like lambda) to fetch and transform in data package. ### Should the app display real-time updates? - potential nice to have - polling and auto refresh TODO: Add to dev spec when we get to build. ### How do we handle massive DAOs? - Foundations learnings: - can't load all data upfront (>3000 members + 30k proposals) TODO: Will need to explore better paginated data fetching ### How do we handle 'blind spots'? - contract functions not exposed in the current ui - single pattern to 'warn' daos/users TODO: Pass to UX ### How should we handle a downed RPC, subgraph, or backend service? TODO: UX to design - need a consistent way to catch these errors and pass to app context - more next: - ### How do we build a comprehensive error handling system? Jord: I'd like to look into some functional programming patterns like pipe/compose for this. I've found it really hard to implement pipe() well (FP is hard), but where it is implemented, it handles control flow really well. ### Where do we set our limits on what this app supports? - data size limits? - see foundations issue Jord: Perhaps a limit we could have is a BYOB (Bring your own backend) approach to subgraphs and other caching services. We cache main contracts and generic minions. Community does the rest. We'll never be able to do data availability for everything, however many boosts might require something like that. Might be good to specify where we draw that line. ### Should we enable the UI to work without custom DAO config/metadata - can this ui work without cached data and extra apps supported by daohaus - like an api - just pure contract interaction version Jord: The more I think about this, the more it seems like a late-stage goal. Sam: Agreed - or even a different app ## Process/Organization ### What is our decision-making process? - How do we do cost benefit? How do we decide what we prioritize? Decentralized vs. centralized decision tree - I think this all goes back to the mission of Daohaus. We should be priortizing for what pushes the mission forward. So, if Daohaus puts decentralization first then we should probably prioritize adopting new decentralized tech earlier than other platforms. Decisions like this won't be costless though. It could lead us to making the wrong bet, or getting bogged down by alpha tech. If we want to be something like the most decentralized building blocks for your daos community than we have to ground our decisions in a framework of how complex a feature is to implement and how much of an impact it has on the mission. (Keating) - Jord: Agreed, but we have a lot of values, and we're not really close to establishing what priority each value takes. So far, we've been able to justify basically anything becuase it could always be part of one of our goals. I think we should have **missions for the project**. DAOhaus has many missions, and we'll get bogged down if we use that as our guide. - decentralization vs. great ux ### Should we continue to benefit from the speed of silos, or should we invest time in switching roles? - The tradeoff here is usually silos can move faster, but knowledge is distributed to the rest of the team. This could cause single points of failure in terms of understanding code and features. It may be better to have multiple people across a few workstreams to avoid this problem. Coordination costs in in the short-term are probably higher, but it should pay off in the long term. Also, having people switch teams will help us understand the quality of our documentation. (Keating) - Agreed. We also talked about working on sections of the app in unison. ### What will be our approach to app security? - contracts - Testing, identifying app blind spots - data layer - Where data is stored - ui/ux: make users feel comfy - free for all boosts dev - curated/review process of boosts - I think for boosts there should be two tiers. A daohaus approved registry of "safe" boosts and then a community tier of free for all community. Messaging should indicate that these community boosts may not be safe. (Keating) - I'd argue that code review and QA is an area where a lot more security focus can be applied. - do we need a work stream/new contributors focused on this ### How do we enforce all steps of process - writing specs, qa, code review, docs - Specs will need to be enforced at the social layer. A PM or ticket will need to hold that. Code review can be enforced in github, and documentation can be enforced in CI at the code level as well as in the social layer. (Keating) - Convo about PM and how we choose to organize (Jord) ### How do we get more people to do code review? - Every core contributor should do code reviews, but it may take time for devs to build up enough context to give a good review. (Keating) - Perhaps to solve this problem, new devs tag along for reviews w/ experienced devs on reviews. (Jord) ### Should QA happen before code review? - Probably not, but basic QA should be part of a code review. Full QA is probably more costly than a code review? (Keating) My reasoning behind this is that QA is more focused on UX and things not crashing. Writing clean JS doesn't really have a whole lot to do with that. If we do QA first, we can save a bit of time by not having to clean the code twice ex. What we do now: Push code up => review => pull back down => correct => push back up => QA => beg for feedback => possibly a lot of changes => push back up => possibly another review What we could do Push code up => QA => beg for feedback => implement changes => push => review => correct => push It saves potentially one step and ensures that the final code is reviewed. (Jord) - I'd love to see non devs doing more QA - product managers/designers (sam) - qa environment ### What is the role of the community dev on the main app? - Is community different from core? (Keating) - Can we push community dev to boosts/boltons - V3 dapp takes more community contribution once launched - also needs pm help Notes from last meeting: - Community is different from core - We'd like community to focus more on boosts - PM would be really helpful for parsing PR and Issues on Github and handing off relevant tasks to devs ### Who writes docs? Should we enforce some sort of rules around docs? - dedicated team? - A doc template would be a good tool to help devs get started and to enforce consistent structure/style (sam) - team sage = code level docs - commnity devs/members make tutorials/how-to use libraries/packages - user level docs === rangers - incorporate into dev flow - dev/cr/qa/docs ### How do we structure package version releases - leverage rage team for alpha testing and 1st round of feedback - [Semver versioning](https://semver.org/) we need more exploration on this. ### Should core contributors be assigned or self-assign responsibilities? - Generally there should be a pool of tasks or projects to do and there should probably be a hybrid approach. People can self assign to that pool, but can also be assigned if core members are actively looking on something to work on. (Keating) - My take on this is that per team (Rage and Sage) the system should be as simple and non-hybrid as possible. If we have a system where one week we sort of do one thing, and then one week we sort of do another, we won't use the system. Personally, I'd prefer to be working on the thing that is needed next for the project. If we make it loose and interpretitive, we'll get roadblocked and distracted. My 0.02 . (Jord) - PM - bug days? - crunch mode - all hands on deck - leverage commitment level contributors ### How do we consistently purge old code? - We probably shouldn't actively purge code, but employ a rule to leave the code better than we found it. So, if a dev sees tech debt related to what they are working then they should remove that tech debt. (Keating) +1 - This is nice in theory, and was definitely the mindset I wanted to have coming into this project. However, I quickly found situations where I would fix a bug, find something wrong, and then have to take 3 days (or weeks) redoing something because of the shape its in...when the bug fix would have taken a half-hour. A shiny new app might help with this, as the app *should* be clean all around. - Also, this doesn't solve the problem we have with pages of unused code that's left over from larger refactors. I'm hoping that with the new app, these larger overhauls will not be necessary, but it's unlikely. (Jord) - user code review process ### How do we organize our files? - I'm not particular on many details, but would like to define a standard/publish and keep everything consistent. (sam) - consistent across packages - need a v3 style guide ### How do we minimize bundles on our app? - Might be part of a build/bundling tool question and something to consider as we make that decision. (sam) - use bundlephobia ----------------got to here ### What boosts/minions/features can we choose not to support on the next build? - UX input here? - How do we deprecate some 'dangling' features that very few people use. For example, we don't need to support every minion on the next app. In fact, we shouldn't. ### How do we decide who works on what next? - PM FTW ### How do we stay focused? ### How can we optimize our communication lines? ### Should we have deadlines? If so, who sets them? Who tracks them? - I am always a fan of soft deadlines as they can communicate priority what tasks we should be working on. At the end of the day these deadlines should guide us, but not bind us. (Keating) ## Tooling ### State Management: Redux vs. Context? - I think it depends on how complex we expect the state to be, and it may be worth looking at even more state mangement libaries like xState. (Keating) - I'd support looking into Redux alternatives if we moev away from just Context (sam) Maybe we could define a quick process for these spoke so others can pick them up: - define what we need - what features are must have - other rubric? maintained package, battle tested, performance/size considerations, ect.. - identify tools - try them - create report for team - pros/cons ### Types: JS vs TS? - Typescript (Keating) (Jord) - COBOL () ### Routing: SSR vs. CSR? - Couple of considerations from the past: - csr has enabled ipfs deployment and usung react hashrouter we can still get deeplinks, not sure that is possible in ssr. - ssr would give us better control of unfurl content (a constant ux request) - I found a tool that does unfurl for CSR. I'll dig it up. It's handled on the Netlify side though. (Jord) - Because we want to decentralize eventually, and because I'd like to keep app queries and txs for the future build, loading a blob of data up front (minus mass proposal, activities, and members) seems essential to me. For that reason, CSR seems the most efficient way to get there. ### Bundling: Next vs. CRA vs. Custom Webpack? - Ceramic webpack 5+ dependency ### Styles: CSS-in-JS vs. Premade Component Library vs. Raw CSS - Jord: After fighting with more Chakra stuff over the weekend, and given that we're making a component library, I think a CSS-in-JS option is best. - Way smaller package size - Faster loading (CSS can generated) - More custom control/can match designs easier - Easier to build atomic components - More composability - More semantic JSX - Allows community devs to build on/off - More people know CSS than chakra (to be fair, Chakra is very easy to use) - Better scoping and control over theming - Faster development in the long run. ### Testing: Jest vs. Chai Jest, right? ### Dev Ops: How do we handle all these small apps? - things to consider: - repo management (multiple or mono-repo?) - currently hosted in netlify & ipfs w/ fleek - api/data cache in aws lambdas - ci/cd - ### Caching: How do we handle more backend caching? - We should probably avoid backend caching as much as we can. If we can get data from dentralized storage and cache on the frontend that would be ideal. It would be good to gather an architecture diagram of the current app to get a feel of what technologies we use and where. (Keating) ### How do we want to handle data storage - do we replicate current serverless data aggregation jobs and look for more decentralized options to replace s3/airtable - do we want to aggregate more of this to create simple documents for the front end to pull from - rewrite serverless functions to use decentralized storage options - unbundle from the permissioned storage - State === decentralized - Aggregation/computation === lambda - [Storage solution deep dive](https://hackmd.io/QDALCjN_SeGq86-DsDkRkw) ### Docs: Are there any tools to make writing docs not suck? - There are different levels of documentation. In code documenation strings and potentially tutorials and guide. For the latter I have used something like hugo which is a static site generator from markdown which was pretty good. (Keating) - https://github.com/TypeStrong/typedoc - https://tsdoc.org/ - We have currently docs on daohaus.club using docusaurus (sam) ## DAO Tools ### Which parts of the app should become packages? - ui - data - could form/tx builder be a package? - I would say so. Perhaps this one is refactored into a package though. - ### What are some efficient ways to maintain these packages? ### Could we get funding for them? ## Big Questions for the Whole Team ### Do we want to have centralized control so we can censor bad actors or should we decentralize so we're not liable for them? - The goal should be to decentralize and build/adovcate solutions to disincentize bad actors. (Keating) - I like this in theory, but it needs to work. What are the projects that are currently knee-deep in this problem, but handling it well? What are these solutions? If we're decentralized, how do we ensure that these solutions are even used? No matter what, if we're even a little bit centralized, I think we'll eventually experience a lot of outside pressure to censor. The worst possible situation is one where we're centralized enough to be liable, but too decentralized to make any effective changes. ### How can we collaberate with other DAOs to build a better app? ex. Diamond DAO and Deep DAO have explore-like services. Could we collab on one awesome service? - There are two approaches I think will be great. Uberhaus grants for projects to collaborate, and us making the frictiion of integrating/building on top of daohaus much lower. One of the things Gnosis is great at is making it easy to integrate other apps into their platform with safe apps. (Keating) + 1 (Jord) ### Should we bring that content layer into the app? If so, what's the best way? I'm going to continue banging this drum. To me, it's the missing piece that is stopping us from wider adoption and active use. We need to back up the 'Purpose Driven DAO' with action. Having a DAO be able to describe their purpose, what they're voting on and why is essential. ## Tech Design Document Outputs - Current and next gen architecture diagrams - Current - SAM - Where data is and where we get it - Performance bottlenecks - data flow into the app/aggregation level - lighthouse report - SAM - Current and refined data models - Legos - JORD - DAO config/metadata - SAM - DAO onchain data - SAM - What is hydrated and where - SAM - Contract interaction map - what contracts/functions - Stack decisions - keating -> https://hackmd.io/BXV-K2j3T9eO6xH89pC1GA - maybe document exploration into solutions - Spec/design/api docs for various systems - data library (at least to get it started) - caching what and how and where - front end - backend - state management - lego reuse or expansion? After UI/UX designs are created - Site map - Component map - atoms, modules, components, ect... - ui library vs custom to app - pages and which components will live on it - Code patterns expansion #### ourses/Learning - Testing tutorials ## Resources ## Current Arch Draft ![](https://i.imgur.com/5ZshwiS.png)