1-860-882-1150info@VIAcode.com

White Papers

Making Mobile Apps Scale

By Polina Cherkasova

Remember when adding a mobile client to an application was considered new, different and nice to have? How quickly we arrived at the point in which the demand for mobile clients is more critical than classic web clients. The capabilities of a mobile client or app are obvious, because we hold the app in our hands; however, the impact of mobile apps on the server side application development and daily operations often escape scrutiny. Here’s the important thing to remember: Every tap on a tablet or smartphone drives a series of server-side actions including processing transactions, retrieving, delivering, or storing data, and communicating between multiple devices, applications and servers.

In our view, the demand for mobile applications has fundamentally changed application development in several important ways.

  • Network traffic patterns differ due to prevalence of more short bursts and synchronizations.
  • Real-time integration across numerous applications becomes standard practice.
  • Security diminishes in the client environment as a by-product of mobility.
  • Predictability of Internet connections weakens.

In this White Paper, we will briefly explore three key topics in back-end mobile development that play a critical role in the delivery of successful, scale-able applications. These include:

  • Recognizing the differences between mobile and web traffic.
  • Choosing the right protocols and architectural approaches for client-server interaction.
  • Understanding the function and behavior of Mobile as a Service (MBaaS) platforms.

Mobile vs. Web Traffic

Mobile devices change network traffic patterns in several important ways.

  • Since small devices accommodate less information per screen, users move quickly through screens sending smaller, but more frequent requests, to the server.
  • For public applications, there are fewer advertisements than on websites due to the smaller screen size on tablets and smartphones; however, the ads tend to be more impactful and have a higher click-through rate. Therefore, they need to be delivered quickly and in a compelling way even though the type and variety of mobile devices in the hands of users create huge testing and delivery challenges.
  • Poor Internet connections affect page optimization. Most rendering and calculations take place on the server side. Thus, poor connections cause bottlenecks on the server side.
  • Mobile applications are in use 24/7 with most usage occurring after regular business hours.
  • Since mobile users operate ‘on the go’, short session times exist, but, because devices are always on and interact automatically with the backend, “check-ins” skyrocket.
  • Digital images, audio and video have now become a significant major component of mobile traffic – even for business-oriented applications.

Client-Server Protocols

In a mobile environment, the number and variety of requests to the server increase as more users access and operate the app. The server side must be fast and flexible as well as elegant. Protocols known as REST and oData play a significant role.

REST

The REST protocol has become a de facto standard of client-server interaction, replacing the traditional Web Service (SOAP) protocol. The REST protocol offers two important advantages:

  • It simplifies API calls.
  • It enables you to reference any object and operation using a URL structured with simple, well-known rules instead of setting up individual procedures for accessing each dataset.

Here is an example comparing an identical call using SOAP and REST:

SOAP CallREST Call
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 <soap:body pb="http://acme.com/phonebook">
  <pb:GetUserDetails>
   <pb:UserID>12345</pb:UserID>
  </pb:GetUserDetails>
 </soap:Body>
</soap:Envelope>

http://acme.com/phonebook/UserDetails/12345

Due to its simplicity, the REST protocol is significantly:

  • Faster in encoding/decoding/parsing/transferring.
  • Easier and cheaper to develop, support, and test.
  • Less reliant on proprietary tools.

Here are some good resources on REST:

  • http://rest.elkstein.org/
  • http://net.tutsplus.com/tutorials/other/a-beginners-introduction-to-http-and-rest/

Query-able APIs: oData

Many applications require multiple views of the same data. Some typical examples might be:

  • Identify the top 30 most popular products by category, sorted alphabetically.
  • Find names and pictures for the top 10 bestselling products overall.
  • Pinpoint the names and prices for the top 10 products currently on sale.

Usually, developers will go to great lengths to avoid maintaining an API method for each view; however, it does not make sense to expose just one API method where client applications “request everything” and then use only the information needed in this request. The server and network loads would be too great.

To resolve the problem, Microsoft has introduced oData which is built on top of .NET lambda expressions and the REST protocol. With oData, your Web API publishes a database schema. Based on this schema, client applications can build queries against the schema and submit them to the server.

An example of how the oData URL query on top of the REST protocol looks:

http://mystore,com/Products?$orderby=Name desc&$filter=Category eq 'Toys'&$top=10&$select=Name,Picture

Here is how the .NET Linq query that produces the URL above looks:

var q = (from p in data.Products 
         where p.Category.CategoryName  == "Toys"
         orderby p.Name 
         select new {Name = p.Name, Picture = p.Picture}).Take(10);

By using oData, developers can create faster, more flexible ways to deliver information to mobile devices and preserve capacity both on back-end servers and the network. Here are some good resources on oData:

Server-Side Architecture

The possibility of creating a Linq query on a mobile device and submitting it to the server side creates a sweet illusion of a direct connection to the database. There are platforms that can automatically generate both an oData server API and client proxy based on your relational database schema. As a result, the illusion of a direct connection requires no coding.

The figure to the right shows such an architecture. Generally, developers avoid exposing all of the details of a physical database in the application API.

As an alternative, you can employ a logical schema for the API generation that includes:

  • Logical schema.
  • Physical schema.
  • Trigger-based business logic between them.

You can find more implementation details here.

There are important things to remember if you use this approach:

  • The business logic of such applications is not procedure-based but event-based. If you do not follow strong coding standards, the implicitness of the operations can cause serious maintainability problems.
  • If your data storage is not relational or if you are thinking of migrating to noSQL technology in future, you will have to invest in the query-ability of the data - which can become expensive.
  • Flexibility to execute almost any query against your database will make your server vulnerable to performance problems. If you have reporting components, do not connect them to your business-critical operational database but to its replica.

We recommend exposing a hybrid API that is both queriable and procedural.

You should expose a queriable API if you can guarantee one of the two following conditions:

  • The flexibility cannot affect the availability and performance of business-critical functionality.
  • Strong mechanisms exist to control the set of queries that client applications submit against the API.

When implementing event-based business logic, you need clear, written rules that describe how the code should be structured. Your development team must understand and enforce that structure without tradeoffs.

Mobile Back-End as a Service (MBaaS)

A number of providers have built services that make operating applications in the cloud efficient, economical and productive. These services fall into three categories:

  • Infrastructure as a Service (IaaS)
  • Platform as a Service (PaaS)
  • Software as a Service (SaaS)

Now, you can add MBaaS (Mobile Backend as a Service) to the list. MBaaS, a subset of SaaS, provides the core functionality of the mobile backend, allowing developers to concentrate on client-side functionality. Current MBaaS offerings provide key services that dramatically shorten development time and cost and potentially increase reliability. Those services fall into eight categories:

  • Authentication and user management
  • Push notifications
  • Storage
    • Structured
    • Unstructured
    • Semi-structured
  • An automatically generated client-side proxy that creates the illusion of direct connection to data
  • Mechanisms for client-side data caching and postponed synchronization
  • Analytics (searching for usage patterns)
  • Integration with other services
    • Social networks
    • Local services
    • Advertising
  • Billing

The following are the most popular players on the current MBaaS market:

MS Azure Mobile, Amazon Mobile, StackMob, Parse, Kinvey, Apigee, Appcelerator, Sencha.io, and FeedHenry.

There are five, critical questions to ask when selecting an BMaaS Provider:

  • How mature is the provider in the areas that are critical for your application?
  • How friendly is the price model with your usage forecasts? Remember that the final bill will depend not only on the traffic and storage size, but also on the use of other services, the number of users, the number of push notifications, the number of analytic reports, etc.
  • How acceptable are the SLA numbers for your business? Limits for data storage? Service availability numbers? Data durability guarantees?
  • How flexible and automated are scale-up and scale-down processes?
  • Is there a mechanism to get your data in bulk and in a standard format from the service provider?

Unfortunately, the nature of the MBaaS niche does not leave room for open source solutions, because software is tightly connected with the host.

In Closing

There’s no doubt about it: Mobile Application Development is the next frontier for IT organizations to conquer. Certainly, users must be happy with the applications they hold in their hands. They must feel productive and enjoy the application experience. Our view is that a successful application experience is as much about what users don’t see. As you create your mobile applications, remember these things:

  • Account for the differences between web and mobile traffic. Failure to account for frequent small data bursts and synchronizations can doom the best looking mobile apps.
  • Use the most modern approaches to Mobile Applications Architecture. Approaches like REST to manage data exchange can make your applications run a lot more smoothly and will create a lot less stress on the internal systems and data sources that feed your mobile apps.
  • Look for services that make your application development process much simpler. MBaaS providers can offer you capabilities that provide stability on the back-end, so that users can have the best possible experience.

About VIAcode Consulting:

Headquartered in West Hartford, CT, VIAcode builds and delivers commercial or “internal” software products that are “difference makers” for our customers. We radically enhance your technical capabilities by deploying world-class technologists throughout the software development lifecycle to meet your application needs on time and on budget.

Contact us at 1.860.882.1150 or Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..