Confirmed users
230
edits
Gaia/Architecture Transition Proposal: Difference between revisions
Jump to navigation
Jump to search
Gaia/Architecture Transition Proposal (view source)
Revision as of 15:42, 20 March 2015
, 20 March 2015→Step 2: Mirror functional teams into the codebase
| Line 99: | Line 99: | ||
= Step 2: Mirror functional teams into the codebase = | = Step 2: Mirror functional teams into the codebase = | ||
While the first step to enable this architecture is to reorganize teams, the same set of changes needs to be reflected into our codebase. | |||
'' | |||
Note: There is no silver bullet to do it, there is only a big amount of work. That said, some rules are defined in order to help.'' | |||
In order to enforce a strict separation between categories, it is suggested to explode Gaia into multiple repositories, such as: | |||
* One repository per application back-end | |||
* One repository per application front-end | |||
* Multiple repositories for shared libraries/helpers/etc... | |||
In order to ensure teams are working asynchronously and a team can not block an other one, it is also suggested to run tests on a per repository basis. | |||
If someone, break the tests of one repository, it should not prevent other teams to continue working. | |||
In order to help for deciding where each parts should lives, a set of rules is defined. | |||
'' | |||
Note: This is not a definitive version of rules. Discussing with individual teams may help to shape the rules.'' | |||
== Toolkit Rules == | |||
* if a composing element is needed by more than one app, it should be the responsibility of toolkit | |||
** Lists | |||
** Navigation | |||
** Web Components | |||
** ... | |||
* if an helper is used by more than one app, it should be the responsibility of toolkit | |||
** Service Worker Helpers | |||
** Data Synchronization Helpers | |||
** Telemetry Helpers | |||
** shared/js | |||
* ... | |||
== Front-End Rules == | |||
* Responsible of perceived performance | |||
* No business code, but only data-binding, reacting to user events and navigating | |||
* No WebAPIs direct access | |||
* No cross-views communication | |||
* Async UI | |||
== Back-End Rules == | |||
* All code runs inside a worker | |||
* WebAPIs code can not run into workers (yet). It should be accessed via the bridge abstraction | |||
* Business code | |||
* No DOM access | |||
* Stateless services | |||
* Specialized service per panel | |||
= Step 3: Scope logical blocks = | = Step 3: Scope logical blocks = | ||