Gaia/Architecture Transition Proposal

Transition Proposal

This is a proposal to migrate our current codebase to the new and unified architecture for Gaia apps mentioned in the Architecture Proposal.

This documentation tries to split the transition process into a multi-steps process. The documentation also try to see how parts of those steps can be done concurrently to avoid a pure linear process.
Note: Similarly to the architecture proposal, it is important to note that this proposal is not a detailed explanation of how to transition individual applications. The details belongs to individual app authors, which have the necessary knowledge of their applications.

Step 0: Mirror the architecture proposal into functional teams

The proposed architecture is about strict decoupling of the front-end and the back-end, and focusing on small pieces. This ultimately lead to fine grained parts, which can be classified into 3 high-level categories.

Those categories are:

• Front-End
• Back-End
• Toolkit

Impact on functional teams

As of today, individuals are often working on those 3 categories at the same time. While some may focus more on one aspect over others, this model merge the responsibilities of all categories and distract individuals.

It also prevent categories to evolve independently and results into a general slow down.

In order to mitigate those issues it is proposed to create 2 new functional teams:

• Front-End
• Toolkit

The existing functional teams will still exists, but with a refocus on the pure back-end of an application.

This solution should also provide a better concerns isolation. For example, most of the time UX/UI concerns are unrelated to the back-end logic. Or many WebAPIs changes does not concerns the front-end logic.

The new structure can be visualize as multiple layers of concerns wrapping each others.

Front-End Team

• One team for all front-ends, of all apps
• Likely a consequent team
• Responsible of perceived performance
• High level of interaction with UX/UI

Back-End Team

• One team per app back-end
• Likely a small teams
• Responsible of business logic
• High level of interaction with WebAPIs

Toolkit Team

• One team for all shared components
• Likely a mid-size team
• Responsible of developer story
• High level of interaction with Front-End and Back-end

Impact on User Story

All those teams can work concurrently, without having to worry about other teams.

It creates an asynchronous development model for User Story. Usually a user story will impact the front-end and the back-end team. Those teams can work on the user story asynchronously, and one team may have done its related part while the other may have not started yet.

But at some point, the front-end and the back-end needs to synchronized to validate the integration. Also both front-end and back-end may independently require to synchronize with the Toolkit.

The backlog of each team is scoped to the responsibility of one of the mentioned categories only. It should create more focused and smaller backlog for each teams, but require some additional synchronization.

As an example the front-end and the back-end should be sure to have a shared deadline for a defined feature. But front-end and back-end may have custom deadlines to work on this feature, as long the deadline if not targeting after the shared deadline.

Step 1: External Services

While applications will work offline, similarly to the current packaged model, applications may benefits from accessing remote servers.

Those remote servers will serve different purposes, such as distributing applications updates, synchronizing user datas and getting telemetry reports from real users.

Those servers should be set up by collaborating with different teams, like the Content Services team for example.

Service Worker

Applications are now hosted with an offline copy of the source code onto the device. A remote server will distribute small updates to the clients.

Each app may distribute an update when a change is ready and validated by QA, and it is not dependent of a specific Gecko version which is not available on the target.

Telemetry

In order to get real reports and application usage, a Telemetry server will be set up. Telemetry reports may contains various type of metrics, keyed by origin, such as the startup time for a specific view, the average number of contacts, or even a navigation map for a particular app.

Those datas may be used for decision making, assuming the correct set of reports is available to the relevant people.

Data Sync

User datas are now synchronized over a remote server. While it can be seen as a backup mechanism, it is mostly a mechanism to enable multiple UIs to access the same set of datas.

A client may then be a desktop application, or a mobile application.