Folks, The discussion between using a js based API or an HTTP API has a lot of values and for my part I see advantages in both. But this is a technical discussion that will better suited its own dedicated thread, no ?
Vivien. On Sun, Nov 22, 2015 at 9:52 PM, Jim Porter <[email protected]> wrote: > On 11/20/2015 10:24 PM, Justin D'Arcangelo wrote: > > One valid reason I’ve heard from Jim in favor of this type of iterator > > callback API is that it would allow the first few records of data in a > > given query to be put on-screen faster. That being said, there are > > several ways to solve the “get data on-screen fast” problem with an HTTP > > API, one of which is to have paginated calls so you can get the first > > 10-20 records super-fast and defer the query for the remaining items. > > Another solution is “better caching” which can be solved any number of > > various ways via ServiceWorkers or other means. > > One of the benefits of a callback-based API over pagination/batching > results into groups is that it's simpler. Obviously, indexedDB already > works like this (indeed, so do many database APIs). Designing the APIs > that will sit "on top" of indexedDB to work in a similar way as > indexedDB keeps minimizes complexity and removes one source of possible > bugs or performance issues. If the Music backend's API used one callback > call per item, our glue code could be quite a bit simpler compared to > code that paginated the results. > > This underscores one of my main issues with parts of the NGA work. While > we can still achieve good performance (e.g. by paginating results or > taking advantage of caching at another level, like in gaia-fast-list), > it requires us to be smarter. For the most part, OGA allowed us to write > "dumb" code and still achieve good performance. We did have > "advancedEnumerate", but that's just a regular enumeration where we skip > the first N results. A hypothetical version of OGA Music that used > gaia-fast-list might not even need that. > > In my experience, the best APIs are the ones that don't force users to > write complex/clever code to get good performance. Good APIs should try > to hide complexity from the user and make it obvious how to get the best > results from it. Then we can spend our effort on other hard problems. > > All of this doesn't mean that Service Workers will never be a good idea, > but I think we'd have to show that they're better for a particular app > than bridge.js (or even than a single-document app). Currently, I think > Service Workers are strictly worse than bridge.js, since the former has > worse performance and fewer features compared to the latter. While being > able to flip a switch and use Service Workers in the Music app is a nice > way to test them out, I don't think this benefits the Music app today. > > Given the choice, I'd rather take advantage of all the niceties that > bridge.js has to offer and then tell the people working on Service > Workers, "here are the things we need in order for Service Workers to > provide value for us." If and when those things are supported, we can > switch to Service Workers, which hopefully will be a relatively simple > task if we've designed our codebase well. > > - Jim > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
