Unified Mono-Repo Discussion

[hmrtn]

It's time we start moving (quickly) towards production Quadratic-Diplomacy.

The simplest approach to defeat Moloch is by using a mono-repo containing all of the supported production versions of Quadratic Diplomacy.

Let's leave this as an open discussion for sharing ideas regarding the project architecture and ideas.

[hmrtn]

Here is what we need:

• A landing page for quadraticdiplomacy.com that briefly explains the different versions, use-cases, and links to each version.
• Unified UIs. The user should always be presented with nearly identical UI's. Consistency is important.
• ???

[carletex]

Hey @hansmrtn, great initiative on using GH discussions!

A landing page for quadraticdiplomacy.com that briefly explains the different versions, use-cases, and links to each version.

I think we could use @willsputra landing page for now (adding the "cards" for each version"). Yes, having a unified App UI is nice, but I'm guessing is going to take a while. Right now, what's in https://www.quadraticdiplomacy.com/ doesn't supply any value, having a landing page with info and link, it does (even if we don't have an unified UI :))

The simplest approach to defeat Moloch is by using a mono-repo containing all of the supported production versions of Quadratic Diplomacy.

So, why are we creating a new repo? I though we were going to use the other repo, with different branches (like scaffold-eth). We could just mark which branches are production ready with a tag / badge / docs or something.

[hmrtn]

I think we could use @willsputra landing page for now (adding the "cards" for each version").

It does look awesome! Here is the link to the landing page design if anyone missed it. Huxwell, I believe, is working on this and opening a new discussion would be a good idea!

Yes, having a unified App UI is nice, but I'm guessing is going to take a while.

Agreed - it will be a steady progression towards a UI that is ammenable to all versions (on-chain, event-driven, meta-txs, etc) and shouldn't be a hard requirement for production.

So, why are we creating a new repo? I though we were going to use the other repo, with different branches (like scaffold-eth). We could just mark which branches are production ready with a tag / badge / docs or something.

The intent of this repo is to facilitate a new unified project structure, and simplified repo management system for the quadratic diplomacy project. I felt that a "clean-slate" for the unified versions would be beneficial and help guide us to all be on the same page. I am totally okay with reverting that decision if this is determined to be unnecessary 😄.

[swapp1990]

If we have seperate branches for different versions, can we use something similar to Vercel for deployment, so every version will have a seperate route, eg. qd.com/onchain, or qd.com/events etc. and qd.com can be a landing page branch as well which links to different versions. Also, how are we dealing with different networks deployment? WIll that be an option on the landing page as well? (Might be a bit overwhelming). We can have the option of switching to different networks on each versions branch, if your version supports different networks.

[hmrtn]

If we have seperate branches for different versions, can we use something similar to Vercel for deployment, so every version will have a seperate route, eg. qd.com/onchain, or qd.com/events etc. and qd.com can be a landing page branch as well which links to different versions.

I am not familiar to Vercel - though I found their documentation on GH integration insightful.

Instead of separate branches for each version, is it reasonable to have development, staging, and production branches each sharing a unified code base as a way to stay in sync and utilize code review/prs more efficiently? e.g.

quadratic-diplomacy
├── LICENSE
├── README.md
├── backend/
├── frontend/
├── event-driven/
├── metatx/
├── on-chain/
└── ... etc .../

Though while writing this down, I am realizing this structure does not easily conform to the scaffold framework and would require some extra tweaks in order to implement. Definitely needs to be discussed.

Also, how are we dealing with different networks deployment? WIll that be an option on the landing page as well? (Might be a bit overwhelming). We can have the option of switching to different networks on each versions branch, if your version supports different networks.

That is a great question! IMO, every production version should be available on mainnet, at least. And if supported, switching to alternative EVM networks can direct the application to a different contract and front-end network requirement. Perhaps it can be a label and toggle on the application's page?

[carletex]

I've used Netlify for deploying my branch (I think it's just a Vercel alternative). Some notes:

• Like @swapp1990 said, you can choose what branch to deploy. Netlify (and Vercel) supply CI/CD out of the box: you just select a branch y and it deploys automatically when that branch is updated.
• We could also use subdomains (instead of /folders). Like event-driven.quadraticdiplomacy.com
• We could use main for the landing page (or a separate repo: see this discussion Unified Mono-Repo Discussion #3 (comment))

Also, how are we dealing with different networks deployment? WIll that be an option on the landing page as well? (Might be a bit overwhelming). We can have the option of switching to different networks on each versions branch, if your version supports different networks.

What I did for my event-driven version:

• Un-ignored & Commited the hardhard_contracts.json file, with all the available networks (where I've deployed)
• Update App.jsx to use env vars:
  
• Added the env var on Netlify
  

We can change that ENV and redeploy without changing the code.

But I like @swapp1990 idea better: We can just have a on-page selector to switch networks (we could read hardhard_contracts.json and check what networks are available)

[swapp1990]

After discussion with @hansmrtn we came up with some plus and minus points for a unified mono version and scaffold type branched versions here:
For unified repo,
plus points:

1. Having a unified structure will make it easier to manage and make easier to organize.
2. Everyone will work on same base ui components and benefit from any updates.
3. consistency for UI and libraries.

minus points:

1. If someone makes changes to a base component, we will need to make sure it doesn't affect other versions already working in prod.
2. Will need to modify scaffold-eth code to make this work.

For scaffold-eth type branches:
plus points:

1. Every group working on a version is independant of others. Fast experimenting and deploying to prod is independent of a core team.
2. Doesn't enforce a common structure/organization for building

minus points:

1. If the version doesn't use up to date libraries or ui components, there will be inconsistencies and chaos.
2. Doesn't enforce a common structure/organizational for building

And I think branched version will work much better for us. But we need to make sure a core dev team is keeping an eye on the branched versions before they are pushed to production website.

[hmrtn]

Branches add some complexity to maintain but I am leaning towards that model.

How do keep organized with the branches model to avoid a mess later?

Looking to hear other opinions, too :)!

[carletex]

I think I also lean towards the branching model.

If someone makes changes to a base component, we will need to make sure it doesn't affect other versions already working in prod.

This is a big CONS for me of the monorepo. PR reviews can get "interesting" :D

[Cali93]

This is a CON if we don't have a CI/CD pipeline and our app isn't properly making use of tests.
And IMHO, this unified repo should be a production ready app.
It is our duty to write clean, secure and well tested code that we can turn into concise PRs with cool reviews.

[hmrtn]

In regards to the landing page, perhaps we can start a new repo called quadratic-diplomacy-home, or something, in order to separate the landing page from the applications - this would probably be necessary in a branched version using vercel

[carletex]

Another idea would be to use the main version of this repo. Since everything is going to be in branches, we can use main for documentation / landing page.

[Cali93]

Hey everyone,

Thanks @hansmrtn for taking this initiative of trying to gather efforts under a unified repo.
Expending on the mono-repo idea, we could use a folder structure along those lines:

quadratic-diplomacy
├── LICENSE
├── README.md
├── CONTRIBUTING.md
├── contracts/ - a hardhat project with a unified contract
├── backend/ - a NodeJS server
├── frontend/ - a NextJS app
        ├── homepage/
        ├── dapp/
                ├── members/
                ├── elections/
                ├── votes/
├── utils/
        ├── event-driven/
                ├── create-election/
        ├── metatx/
                ├── create-election/
        ├── on-chain/
                ├── create-election/
        └── ... etc .../

[damianmarti]

I think that we must use a unified repo too, with a folder structure like the @Cali93 proposed, with a unified UI and an unified contract.

[swapp1990]

I agree too. The different branched version would have been a good idea if we were working on completely divergent smart contracts, but it looks like most of the versions will work with a single contract. So having a unified contract and UI with plug and play options would be the way to go.

[Cali93]

This is the CodeSandbox I was playing with during the d-dip core meeting:

This approach would rely on using utility functions and writing different "onSubmit" handlers.
The admin of the election will choose which type of voting he'd like to use (set default voting type in admin settings?):

• on-chain
• hybrid
• off-chain
  The user will be prompted to vote for other candidates and a highlighted text should show which type of voting is used for that specific election.