Break down of govtool in pillars / services

[l-br1]

notes from 9th, 16th April 2024 - govtool all

Separate as much as we can, and wrap up those in pillars.

---

Glossary

• 🏛️ Pillar: Foundational component or module that encapsulates a specific set of logic, services, and user flows, which collectively function as a distinct entity contributing to the overall structure and functionality of the system. A pillar can live without the other pillar. These represent wide product areas. GovTool is made of multiple pillars. Within pillars we have services. For example the Delegation pillar is concerned wholly with providing all the functionality needed for DReps to register, ada holders to discover and delegate to DReps. Pillars on the product equal to services on the engineering side.

• ⚙️ Components - Unit of functionality within pillar, in a npm package, made up of multiple feature components. Separation of concern.

• 🎀 Wrapper - One or more pillars integrated together. Contains its own shared services which provide it's pillars with shared libraries/utilities.

---

🎀 Govtool Wrapper:

• shared wallet connect
• shared CSL
• shared metadata service
• fe component lib(?)
• State management
• (imported pillars)

GovTool breakdown

🏛️ Pillar: Governance Action Proposal

Description: Full user flows around, creating off-chain proposals, discussing them, polling interest and then submitting on-chain to become governance actions.

⚙️ Components:

• proposal creation
• proposal commenting
• proposal polls
• governance action on-chain submission (this relies on the metadata anchor pillar, but applies the governance action template CIP from within this pillar)

🏛️ Pillar: Voting

Description:

⚙️ Components:

• DRep vote submission
  • Submit DRep vote rational
• Display GAs
• Display votes

🏛️ Pillar Delegation

Description:

⚙️ Components:

• DRep registration
• Delegation to DRep (/ DRep directory)

[l-br1]

finalise initial structure of the above in the govtool all call

[kickloop]

cc @MSzalowski

[Ryun1]

architecture discussion call - 2024/04/22

Discussion:

• How to do routing for the proposal discussion forum?
  • Route to PDF from base govtool
• How do we wrap each pillar?
  • in its own web app and export as a dockerized image? Or do we split via logic + npm package
  • when building the app how is it done/work?
  • We have a BE and a FE
    • BE can be whatever - can centralise them with message or not
    • FE we should repack each pillar as an NPM lib, then each can be imported into the super wrapper app, each inherit higher level functions such as wallet connection.
• Do we treat current GovTool as a wrapper?
  • yes, we just repack
  • we take current govtool, we take out all pieces to do with voting
  • we then place the voting in its own npm lib, and then that is imported into current govtool
  • does this include complete pages?
    • yes, we should build the whole thing in storybook so it is stateless
• Wrapper contains just side bar and header and footer
  • with the pillar opened and rendered within, as a separate app
  • Spotify is inspiration - todo add link
• summery
  • For the BE services we will have an image for each
  • For the FE we will have image of the wrapper plus imports
    • for delegation pillar - are the same as CSL or any other import into project, but we will have UI also
• lets test with one pillar - Proof of concept
  • lets create an app that does whatever and import it into existing govtool
• every pillar should include logic?
  • every pillar should work as a standalone app (but not its own app :) ), so logic and UI
  • business logic and UI
• Should every pillar be its own repo?
  • In one repo or in multiple repos?
  • For now we can divide between teams
  • When separating between repos we divide it more strictly in our minds

Next steps:

• @MSzalowski to repack the delegation and test it out, importing into govtool
• Lets dig into how this is being done for the website: https://github.com/IntersectMBO/intersectmbo.org-clone

[Ryun1]

@kickloop lets standardise the naming conventions of these packages

Lets just go with;

• govtool-

[MSzalowski]

Branch with the wrapper - feat/695-govtool-wrapper
For time being let's just push the needed wrapper logic to that branch without passing it to the develop treating this as a POC

[Ryun1]

Notes from 2024-05-22 - Engineering

Highlevel:

• Postpone the splitting of Govtool, but not the whole new architecture

Notes:

• Currently in assembly we have the core wrapper parts, as described above.
• Wallet APIs are shared and can be used.
• Complexity in splitting current monolithic-govtool into pillars.
  • not to easy
  • can cause some new bugs before beta release
• @MSzalowski's proposal; for the 19th June.

  • combine current mono-govtool with Proposal discussion pillar

  • proposal discussion pillar imported into to current GovTool

  • proposal pillar, talking to ga submission via message queue? possibly - this saves us from splitting the current govtool

  • potential time estimate; once PDF ready, it can be integrated -> a week and a half in between PDF being ready and deadline for being on beta.

  • pillar splitting can keep being done in parallel

  • Pros

  • we would reuse the well tested mono-govtool

  • Sandip likes it :)

  • does not break existing functionality

  • within current contract's scope

  • Cons

    • still need to divide into pillars at a later date
    • integrating other pillars into mono-govtool, DOES add complexity. (this might take time, but can be spotted early)

Environments;

• Handover to Bloxico will be near term, Byron hosting until then
• For June 19th
  • to release the current block of work and above proposal
  • Intersect internal alignment needed first.
  • Byron proposal also useful.

https://miro.com/app/board/uXjVMF-hg-I=/

[Ryun1]

How does this use the new architecture?

• change current govtool repo/code to act as a wrapper, sharing APIs to pillars
• use unified APIs (same as PDF) so that it can be imported into and combined with current govtool

Diagram

Open Questions;

• How are we sharing state/info between?
  • One approach; govtool-assembly imports each components from the npm registry (perhaps easier and has been tested lightly)
  • two approach; host each application/web app separately and then use some communication bus between?
  • three; sharing props between packages

Next step

• Let us (Michal and Nikola) test if this components approach (option one) works? - tomorrow call :)