Transition to Modules

[rafd]

There is an effort underway to significantly refactor the code-base to be organized as "modules".

Background

Most of Braid's code is organized around technical layers ("views", "client-side-state", "websocket-message-handlers", "db", etc.). Adding a feature (such as, say, "starring a thread") involves changes throughout the entire stack, and the code being peppered throughout multiple files:

                      server            client

             http      db      email      ui     ....
          |        |        |        |        |
emoji     |   e    |   m    |   o    |   ji   |
          |        |        |        |        |
          |        |        |        |        |
          |        |        |        |        |
search    |   s    |   e    |  a     |  rch   |
          |        |        |        |        |
          |        |        |        |        |
....      |        |        |        |        |

src/
  braid/
    client/
      desktop/
      gateway/
      mobile/
      bots/
      quests/
      ...
    server
      api/
      db/
      quests/
      search/
      crypto
      ...

"Modules" involves re-factoring the code so that each "feature" lives in its own folder. New functionality would be an addition of code, rather than a modification of previous code ("open to extension, closed to modification", "aspect oriented programming").

               msgs     db       ui      email
________________________________________________

emoji        e         mo       ji
________________________________________________

search     s     e     a       rch
________________________________________________

/src
  /braid
    /core
      ...lots of stuff here, organized similarly to now, smaller as we extract into modules
    /search
      ...one or more files, organized as necessary
    /emoji-provider
    /emoji-one
    /file-upload
    /file-upload-search
    /dropbox-file-upload
    /oauth-provider
    /github-oauth
    /google-oauth
    ... (lots of other modules)

One way to think about it is: currently, our separation-of-concerns is based only on "technical concerns", whereas the change to "modules" would add "product functionality" as concerns as well.

Motivations

Modules should hopefully:

• make it easier to understand the system by better separation-of-concerns
• make it easier to add new functionality without regressions
• make it easier for new developers to add features
• lead to "better" code (less coupling, more pleasant APIs, etc.)
• make testing easier
• foster the development of optional non-core functionality

Progress

We've thought a lot about the "api" of modules, and iterated it multiple times. Improvements to how "modules work" will continue, and tracked in this milestone and this issue .

We've transitioned the code into a core module, and extracted a few modules out of core (quests and various emoji modules).

The Braid Module Graph project exists to help visualize what modules could be extracted and how they could be related.

Next:

• decide on changes to 'how to do modules'
• refactor quests and emoji according to the changes
• come up with prioritized list of other modules to extract out of core (in this issue)
• gradually work through the list

Modules

• quests
• emoji
• emojione
• custom-emoji
• big-emoji

[jamesnvc]

#190 turns bots into modules