On 20 November 2015 at 10:18, Vivien Nicolas <[email protected]> wrote:
> > Having a dedicated set of people that works on it, is definitively part of > the plan that nobody knows but is the companion of the new architecture > proposal: Architecture Transition Plan > <https://wiki.mozilla.org/Gaia/Architecture_Transition_Proposal#Toolkit_Team> > Wow, thanks for sharing this. Firstly, I really love the fundamental principle of the new architecture to split the web apps into a REST API and a front end. This separation of concerns is well established good practice in web development. Service Workers will give us the magic we need to make this work offline. I also really love the idea that the apps that make up Gaia become real web apps with real URLs on the web which can be updated independently of Gonk and Gecko using the web's built in update mechanism, not reliant on giant OTA updates. This is the way of the web. I also agree that Web Components are complimentary to this architecture and are solving a different problem. On the transition plan, I think the front end/back end split makes perfect sense from a technical point of view, but I'm very concerned about the idea of reorganising our 100+ person team into a front end team, back end teams and a toolkit team. This organisational structure seems like it would be a nightmare for our EPMs as virtually every single feature we develop would have cross-team dependencies. Cross-team dependencies kill our productivity, especially given the distributed nature of our teams across timezones. It's bad enough having Gecko dependencies for Gaia features,representing another level of architectural abstraction in our organisational structure seems like a recipe for not moving anywhere fast. Let me give you an example of a user story, "As a user I want to create a playlist of songs". Implementing this feature would require an addition to the API (media back end team) and also an addition to the UI (front end team). The front end team now has dependencies on the back end team and has to file user stories in their backlog like "As a Gaia developer I want to add a playlist", "As a Gaia developer I want to remove a playlist", "As a Gaia developer I want to add a song to a playlist" etc. Now imagine this new UI requires a new or modified web component - the front end team has a dependency on the Toolkit team. Now imagine it requires some platform support for streaming M3U playlists, the back end team now has a dependency of Gecko. All these pieces have to be implemented by all of these separate teams in their separate timezones with clearly defined interfaces for one feature to be completed. Then Product or UX change the requirements (inevitable) and the whole process has to start again! I think the new architecture does give us an opportunity to make a change to the way we manage our teams. It gives us the freedom to create even more autonomous cross-functional teams like the media team, productivity team and communications team who have less dependencies on the wider project and can move fast to deliver updates on their own timescale. Whilst I agree with the front end/back end split and shared components, I think directly mapping the architecture onto our organisational structure is maybe a bit simplistic and could be a recipe for disaster. My view is that what we need is agile, autonomous, cross-functional teams who specialist in one product area. We probably need the existing specialists in those apps to carry out the front end/back end split in the first place anyway. I wouldn't have a clue how to create a front end or back end for our music app, but the media team does. One other more technical comment is that one part of the architecture I don't understand is why our "back end" pieces and our "data sync" service are not the same thing. Wouldn't web apps usually work by having a server-side REST API where all the data is stored, then multiple front ends on different form factors which talk to that API and cache data on the client? Why are we creating a web API which stores its data locally then syncs via a separate service? Is that just applying native Firefox app development thinking to web development? BTW, thanks for having this discussion in the open :) Ben <https://lists.mozilla.org/listinfo/dev-fxos>
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
