Confirmed users
230
edits
| Line 103: | Line 103: | ||
While the first step to enable this architecture is to reorganize teams, the same set of changes needs to be reflected into our 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 | ||
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.'' | 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: | In order to enforce a strict separation between categories, it is suggested to explode Gaia into multiple repositories, such as: | ||
| Line 134: | Line 128: | ||
* ... | * ... | ||
== Front-End | == Front-End / Back-End divorce == | ||
This is nothing else than a long iterative process. | |||
[[File:Gaia Transition Proposal Code Transfer.png]] | |||
The end goal is to have those parts running in a pure independent fashion, with well defined scopes. | |||
[[File:Gaia Transition Proposal Goal.png|300px]] | |||
One likely scenario is that instead of reaching the ideal goal, the final results will look a bit funny. | |||
[[File:Gaia Transition Proposal Likely.png|300px]] | |||
In order to avoid that, a set of strict rules is defined for each parts. | |||
Front-End: | |||
* No business code / Only data-binding and user events handling | * No business code / Only data-binding and user events handling | ||
* No WebAPIs access | * No WebAPIs access | ||
* Async UI | * Async UI | ||
Back-End: | |||
* All code runs inside a worker | * All code runs inside a worker | ||
* WebAPIs code can not run into workers (yet). It should be accessed via the bridge abstraction | * WebAPIs code can not run into workers (yet). It should be accessed via the bridge abstraction | ||