Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How Apps and APIs are Changing the App Acceleration Game

DZone's Guide to

How Apps and APIs are Changing the App Acceleration Game

Knowing how modern app structures and development techniques are changing architecture and services is essential to keep improving performance.

· Mobile Zone
Free Resource

Download this comprehensive Mobile Testing Reference Guide to help prioritize which mobile devices and OSs to test against, brought to you in partnership with Sauce Labs.

Modern apps are changing. And I’m not just talking about the rush to containerize apps or put them in the cloud. I’m talking about app architectures and, more specifically, the techniques behind them that are having a significant impact on networking and app services. No, not microservices or containers. I’m talking about how apps are composed and the division of duties within an app's architecture.

Way back in the early days of the web (in the ‘e-commerce’ era), the need for speed propelled a number of “acceleration” technologies into data centers everywhere. These “front-end” acceleration services were focused primarily on caching and compression at the time. It was an appropriate response to an app model in which the server-side response bore most of the burden for delivering an app. The traditional “layers” of an application- presentation, logic, and data- were all bound up in a single – often large – response wrapped up in HTML.

Web 2.0 and AJAX started to change that. More of the presentation layer of the app was moved onto the client (the browser). Responses became smaller and the notion of dynamic content drove us toward newer acceleration techniques designed to address the unique challenges of these applications. Image optimization, inlining scripts, and reordering of content became an expected response to improving the speed with which these apps performed. Connection (TCP) related optimizations became imperative as a single web app started to consume often eight times the number of connections (and commensurately, compute and memory) to achieve the dynamism users craved.

app archs impact cs responsibilities

Today, REST-based API-driven apps are becoming (if they aren’t already) the norm. At this point, presentation logic is almost completely contained within the client via JavaScript-based frameworks like JQuery and Angular.  The presentation layer has always been (necessarily, some might say) the fattest of the three layers. That remains true, but with most of it constrained to the client (browser or native mobile app), the burden on the server-side has been dramatically reduced. Responses to queries are now JSON, for the most part, and often fit within the somewhat restrictive size of a single packet (about 1460 bytes). HTTP/2 and WebSockets with request pipelining capabilities and binary payloads have made connection (TCP) management on the client side nearly impotent in terms of improving performance because it’s implicitly included in the protocols themselves. The days of needing to multiplex connections are gone thanks to protocols like SPDY and HTTP/2 that provide the same result and require only a single connection.

For most apps, the images that used to provide visual cues (the icons) have moved from individual images to sprites to web icon sets from offerings like Font Awesome. With relatively tiny footprints, such icon sets provide the same visual cues at a greatly reduced data footprint and reside client-side, not server-side, making image optimization less of a problem for most modern applications.

The scripts driving the UI and app logic on the client side, too, are almost universally offered in an already minimized form. Developers know to grab the “.min.” script for deployment and judiciously load them from their hosted sites – already backed by a CDN and cached for more immediate and timely response. page composition one yearIn the past year, the percentage of HTML being served via a CDN has risen to 20%. For JavaScript, it’s 21.5% of the Quantcast Top10k and 7% of the BuiltWith Top Million.

But Lori, you’re thinking, then why is the average size of a web page going up and not down?

Well, all those scripts and presentation logic are heavy. The actual size of a web page is going up because it’s now containing much of the presentation and logic that used to be delivered from the server. It’s still delivered initially by the server, but then most of the actual interaction with the app occurs dynamically, with very small chunks of data being exchanged with the server side logic. Consider the change in the composition of a “page” over the past year. Where fonts, JavaScript, and CSS have increased, HTML has actually decreased by 18%. That’s a significant change.

What this all means is that the focus of “front-end acceleration” services is changing, necessarily. The focus has to shift from manipulating and modifying content to streamlining and managing protocols. Compression may be beneficial – particularly on the first visit to an app – and caching thereafter, but performance improvements where modern apps are concerned will be best achieved through the use of protocols like HTTP/2 and optimization and offload on the server-side of the equation.

Apps are changing; not just where and in what they’re deployed, but their basic composition. That means the technologies and tools traditionally used to improve performance and address capacity issues has to change, as well. 

Analysts agree that a mix of emulators/simulators and real devices are necessary to optimize your mobile app testing - learn more in this white paper, brought to you in partnership with Sauce Labs.

Topics:
mobile ,mobile apps ,app development ,development tools ,api

Published at DZone with permission of Lori MacVittie, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}