On 20 November 2015 at 19:36, Jim Porter <[email protected]> wrote:
> While using HTTP internally might allow for some new features (like > running the backend on a different system), Exactly, what if the back end could run on a server as a web service, with a Service Worker as a progressive enhancement to make it work offline? What if the app could work in multiple browsers? What if that API was also accessible by other apps so that we didn't have to use proprietary cross-app messaging APIs? What if that cross-app messaging could also work locally using cross-origin Service Workers? What if we could replace other local proprietary JavaScript APIs in Gecko with web services? > To be clear, if we can get significant performance gains from using HTTP > and Service Workers internally (e.g. by taking advantage of caching), > then by all means, let's use it. However, our experience with Service > Workers hasn't borne this out yet, and it still doesn't mean that the > easiest-to-use API would be HTTP-based instead of Javascript-based. I don't think a REST API as a back end is inherently easier or more performant, but it is good practice, it is the web, and it does make our code much more portable. Currently Gaia is not of the web. Even > if we used HTTP internally, we might find it preferable to expose an API > that takes advantage of all the syntactical niceties of modern > Javascript. In fact, this is pretty common in many languages, even ones > where HTTP fetches are super-easy: somewhere on top of the HTTP API lies > a language-specific API that handles query-building and response parsing > for you. These "wrapper" APIs can reduce the verbosity and improve the > readability of any calls to the HTTP endpoint We could do that too.
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
