Review Arranger 3.0 Approach

[b-f-chan]

Task for @caravinci to review proposed Arranger 3.0 approach before we do a more detailed task breakdown and start development:

https://wiki.oicr.on.ca/display/OV/Arranger+3.0+Planning

Take this time to review the strategy and do own investigation/analysis of codebase to make sure it aligns with proposal.

Comments/questions can be added to the Wiki page, but feel free to add any tangential notes in this ticket.

[justincorrigible]

Tasks:

1. ~Review document, give preliminary assessment of work for stage 1 (restructuring modules while keeping feature parity).~
2. Study internal structure of the server modules, in order to implement new features, etc.
3. ~Amend this comment~

Dependency tree:

• Admin-UI: // as it turns out, the import seems to be unused
  • ~admin:~
  • ~mapping-utils:~
    • ~middleware~
  • ~schema:~
    • ~mapping-utils:~
    • ~middleware~
    • ~middleware~
• Components:
  • mapping-utils:
  • middleware
• Server:
  • admin:
  • mapping-utils:
    • middleware
  • schema:
    • mapping-utils:
    • middleware
    • middleware
  • mapping-utils:
  • middleware
  • middleware
  • schema:
  • mapping-utils:
    • middleware
  • middleware

Seems middleware is the tip of every dependency branch, I'll start disbanding modules there, and see how the resulting duplicated code will eventually converge (or change, depending on a specific module's needs). Will have to keep a close eye on what becomes dead/unused code when imported. The idea is that the resulting "final modules" will have SOME duplicated code, but the least possible.

Afterwards, mapping-utils, which frees the components library, and relies directly/only on middleware.

Finally,schema will make admin an absolute unit; importable from Server ~and Admin UI, at which point we'll have a clearer sense of how to proceed in order to make the admin-ui a stand alone portal that should talk to the server directly.~

After that if all goes according to plan, we can start adding new features and refactoring code, typescripting things, etc.

---

For ease (and safety) of implementation, I'm creating a new branch based on develop, called main, which I'll merge changes to; and will eventuall replace master (finally).

[justincorrigible]

After further study of Arranger (as it turns out I wasn't very well aware of how it fits in with a client app until now), the right approach is to first set up a mock portal, in which changes to the services are testable live while work is being done.