<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I've watched the presentation of github and facebook doing
GraphQL at <a class="moz-txt-link-freetext" href="https://www.youtube.com/watch?v=wPPFhcqGcvk">https://www.youtube.com/watch?v=wPPFhcqGcvk</a> with
interest.</p>
<p>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.</p>
<p>Also, this isn't new to mozilla, per se.
<a class="moz-txt-link-freetext" href="http://www-archive.mozilla.org/rdf/doc/aurora.html">http://www-archive.mozilla.org/rdf/doc/aurora.html</a>, just to scare
folks.</p>
<p>Axel<br>
</p>
<br>
<div class="moz-cite-prefix">On 10/10/16 22:44, Richard Newman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOjG3JCdWgWyqqa_JG8i7w5gbzEj_E6PWYcQDsj_TLzpFnLteQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Simple
bugs cannot be fixed easily because of gazillions of
unexpected<br>
dependencies. … Having clearer boundaries inside our own
code is critical, too.<br>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">(That's totally normal, but I think our
codebase's emphasis on modularity has if anything made the
problem worse, not better.)</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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?</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">So yes, clearer boundaries — but they
should probably not be the boundaries we have now.</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
firefox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>