Why You Should Build Apps With An API Backend – BaaS

Vector concept of mobile software application development processThere are two divergent trends happening in mobile development right now. The most common one is the mobile-first approach strategy. You construct a landing page website and then build a product in iOS, if targeting the U.S. market, or Android, if targeting the European market. Then, you push a single version and develop for other markets down the line.

The other trend is the API-first approach, in which the underlying construct — the application programming interface (API) — is built first. This strategy allows the website and apps on various platforms to be built on top of the same basic conditions. If your sole target audience is iOS users, perhaps a mobile-first strategy works for you. However, the downside is this hinders quick development for future audiences, including Windows, BlackBerry, Android, and a web-app for your non-mobile users.

The API-first solution allows app developers to quickly reach subscribers on many different devices. With this strategy, you can build, deploy and manage the whole mobile lifecycle from one source using an API Backend as a Service (BaaS). Perhaps most importantly, BaaS allows you to save time and money while scaling your business rapidly. And, according to Markets and Markets market research firm, BaaS will be a $7.7 billion market by 2017, so we see BaaS as a safe bet.

What is Backend as a Service?

Servers and CloudsAlso known as Mobile Backend as a Service, BaaS or MBaaS, Backend as a Service is a way for developers to link to back-end cloud-based storage, most often for push notifications, data storage, file storage, messaging queues, monitoring and configuration, and social integration. BaaS as an alternative to traditional development, bringing more services to your customers in a quick mobile format.

Tim Anglade, from Apigee, a corporate retail-specialized API company, prefers API backend as a term “because it really exemplifies API as the center of your architecture and center of the backend.” Anglade sees API backend as the “key to helping companies deliver their mobile products in time and budget.” BaaS is helpful when delivering your first mobile app, and becomes key when delivering ten or twelve apps a year.

How API Backends Are Designed for Today’s Apps

An API backend unifies many of the development steps that you would typically repeat for various OS and mobile devices, with one block of functionality to remodel on top of. BaaS is built for the world we live in where the quantity and complexity of apps grows exponentially year after year. Anglade believes this is key for helping smaller developers “getting more done faster,” leaving more time to focus on an app’s core differentiating value and user experience.


Anglade’s condensed API backend stack

“In essence, if you were starting fresh today to reinvent architecture for mobile – instead of dealing with your architecture for mobile – this is what it’d look like, right?” said Anglade, as he pointed to the condensed MBaaS stack. This also makes it simpler for app developers, as these customers only need to pair a less complex, smaller Software Development Kit (SDK) with the API.

Tim Anglade, from Apigee gave a talk on building apps with an API-based backend at a Nordic APIs event in Stockholm.

Three Main Benefits of BaaS to the Developer

  1. Eliminates redundant stack setup for each app.
  2. Eliminates boilerplate code.
  3. All within one model.

Together these benefits help developers build native mobile apps faster with greater ease. Instead of worrying about REST API code semantics and dealing with security models such as OAuth implementation, a developer only needs to learn three or so repeatable lines of code: connecting to the account, mapping to the collection and filtering down.

Of course this is all dependent upon API providers offering an SDK, but nearly all have iOS, Android and JavaScript. SDK support for JAVA, .NET, Ruby, Ruby on Rails, Python, and Node.js is growing as well.

If you already have your own Data Source, you can bring-your-own backend with an API Gateway. Anglade believes this has the same ease of use and unified access control while still looking like a singular API.

security ebook blog post CTA 2

What Are the Drawbacks of Backend as a Service?

  1. It’s very data-centric. Opposite to a Platform as a Service (PaaS), an API backend is data first, code later. This means you can’t have long-running functions. However, you can define short validators and calculators. Or you can define things like “When a new order is created, trigger that.”
  2. All the logic gets pushed to the client. Usually adapted to by having a very thin server, delegating as much of the logic as possible to the clients.
  3. Security. More so than with a regular API, Anglade warns that you should be hyper-aware that the clients are in an untrusted environment, and that you should always use end-user credentials on top of the usual SSL and OAuth.

BaaS Joins API-first Design Movement

As mentioned previously, the practice until now has been to design a website or application and then to build an API to connect it to others. Manfred Bortenschlager, API market development director at 3scale.net, argues we change this process to first describe the interface. Therefore, everything that goes through a system goes through the API, enabling websites, mobile apps, and desktop services to be standardized through a single interface.

How Can Business Benefit from Designing API First?

For those readers unfamiliar with API business strategies, Bortenschlager gives four use cases demonstrating different benefits from offering an API:

  1. API as added revenue source: A restaurant releases its daily menu and reservation availability via API. A third-party developer like Yelp or TheFork would like to access that information. The restaurant could choose to simply leave it free for branding purposes, charge each time information is retrieved, or simply charge monthly, for example.
  2. API increases brand awareness: TripAdvisor uses Mulesoft to expose its API to make available photos, reviews and ratings data, as well as a separate Hotel Availability Check API. Outside of TripAdvisor’s website, those hypnotic owl eyes leave hundreds of thousands of brand impressions daily.
  3. API fosters open innovation: Fitbit fitness tracker opened up its API in 2011 to allow third-party developers to create fitness apps based on its health data. Twenty apps were created in the first two years, saving Fitbit $1 million in R&D.
  4. APIs increase efficiency: “API-first design approach helps a lot to internally structure your IT system and architecture, and also helps you to maintain your architecture better,” said Bortenschlager. This is also known as “eating your own dog food” — you maximize efficiency and continue improving your API internally.
For more advice on API business potential, check out 5 Ways APIs Will Increase Your Revenue”

The Downside of Building Your Own Mobile Backend: Six Sarcastic Side Effects

Building your own mobile backend for each different operating system requires varying skills and expertise, increasing development expense and time. Anglade identifies 6 negative side effects that result from taking the DYI route:

  • Acute Apache Anxiety from complex configuration setup
  • Going to PHP frequently to extend your app backend
  • Torn ACL as you try to figure out access security
  • Sysadminitis or what he calls the struggle to access the backend of large company servers
  • Chronic Hipster Dysplasia who think they know better
  • uh AWS! When Amazon goes down and no servers are responding

You end up writing a lot of repeat code that never seems to be error-free. Finally, you are stuck with a large amount of complicated models, legacy systems, servers, file servers, JavaScript, JSON, and the list goes on, with the stack changing each time you switch from one mobile operating system to another.

So, Who Is Building My API Backend?

At Nordic APIs, we recognize that you may not have the time to build the almighty MBaaS yourself, which is why we offer you the following list of sample BaaS providers with the tools to get the job done. Non-exhaustive, and in no particular order:

  • PIGGATE: BaaS for iBeacon and physical web development.
  • BaasBox: Open source backend for your mobile app.
  • Backendless: Allows developers to have an instant backend without writing server-side code.
  • Kinvey: A BaaS with frontend and backend, built for any device or website.
  • Appcelerator: An BaaS targeted at the Enterprise audience.
  • AuthRocket: Mixes an API backend with Auth and user management.
  • GameSparks: The top backend platform, specifically for game developers.
  • Stamplay: A modular backend platform for web developers.
  • DreamFactory: An open source mobile backend that auto-generates RESTful APIs.

Have you worked with a BaaS that’s not on our list? Tell us below!


Also often called Mobile Backend as a Service, BaaS, or MBaaS, an API backend is a way for developers to link their software and application to cloud-based storage, making it easier to link up with software development kits and APIs.

One of the main reasons developers are choosing BaaS is because building your own mobile interface takes time and resources, as processes need to be duplicated and then customized across various mobile providers. With a consolidated BaaS, you can rapidly build on top, regardless of the operating system you’re connecting to. It’s part of the API-first movement that allows everything from website to mobile apps to be built more quickly on top of an API.

Developers love the BaaS approach because eliminates redundant stack setup and boilerplate repeat code, and everything is in one place. However, an API backend isn’t for everyone. It’s very data centric, can send more to the client then you may like, and, if not managed correctly, it can create bigger security risks.

BaaS is just one of many ways that APIs are changing the way we develop, design and live. At Nordic APIs, we think the benefits of APIs are endless. What do you think the great almighty API will do next? Tell us below and then learn more about it at one of our our upcoming events in Copenhagen, Munich, London and Seattle!