Followup: modularity, WebExtensions, and going faster

[Axel Hecht]

I've watched the presentation of github and facebook doing GraphQL at 
https://www.youtube.com/watch?v=wPPFhcqGcvk with interest.

In a similar vein to what Richard is saying, they're moving the api 
boundary from what the service provider can offer to what the client needs.

Also, this isn't new to mozilla, per se. 
http://www-archive.mozilla.org/rdf/doc/aurora.html, just to scare folks.

Axel


On 10/10/16 22:44, Richard Newman wrote:
>
>     Simple bugs cannot be fixed easily because of gazillions of unexpected
>     dependencies. … Having clearer boundaries inside our own code is
>     critical, too.
>
>
> To address just this little part (again): lots of interactions and 
> close behavioral coupling between two modules is — in the absence of 
> lazy design, which I don't think is our problem — an indicator that 
> after years of evolution those module boundaries are drawn in the 
> wrong place.
>
> (That's totally normal, but I think our codebase's emphasis on 
> modularity has if anything made the problem worse, not better.)
>
> I think Sync and Places (and Satchel, and pwmgr, and…) are a great 
> example of this: with the benefit of hindsight, having Sync and Places 
> be totally separate modules — indeed, Sync started off as a separate 
> add-on: very Go Faster! — with Sync trying to track very low-level 
> Places changes via observer notifications, is/was entirely the wrong 
> thing to do. Syncing is a cross-cutting concern.
>
> We flipped this around on iOS, with storage exposing very narrow APIs 
> to the front-end and taking on the burden of tracking changes for 
> Sync. Tightly coupled, deliberately very constrained… but small, 
> correct, and simple. The module boundaries are drawn between front-end 
> and storage, not between bookmarks and Sync tracking.
>
> I betcha there are other cross-cutting concerns, too, and I'm curious 
> which other ones people see. Perhaps with the advent of rAC and fancy 
> form fill we wish we didn't have a division between form fill and 
> password management? Maybe we wish the favicon service were more 
> general to support page summaries and tiles?
>
> So yes, clearer boundaries — but they should probably not be the 
> boundaries we have now.
>
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161010/b0fdeab9/attachment.html>