On 11/19/2015 11:19 PM, Justin D'Arcangelo wrote: > What NGA brings to the table, in this regard, is the ability to craft > an easy-to-consume developer API for the app. When we talk about > separating the front-end from the back-end in terms of “NGA”, we are > really talking about defining this developer API for the back-end and > exposing it via an HTTP API. This allows a traditional web developer, > who is used to working with server-side HTTP APIs, to jump right in > and get up and running.
How does an HTTP API make things easier than a similarly-designed (and likely more-expressive) Javascript API? I absolutely disagree that NGA provides any new abilities to create pleasant APIs for the backend of an app. While using HTTP internally might allow for some new features (like running the backend on a different system), that doesn't mean that the API itself needs to expose this, nor does it mean that the *interface* has improved because of it. Since Firefox OS assumes that all our apps will be written in Javascript, why not take advantage of that property and write the API for our backend *as* Javascript? I doubt that any "traditional web programmer" would be confused by a Javascript-based API as opposed to an HTTP-based API. 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. 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 - Jim _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
