13 Comments

Summary:

The London-based backend-as-a-service outfit thinks not enough mobile developers are considering the opportunities afforded by opening up their apps’ data to other apps, and it wants to help.

Cloudbase founder Stefano Buliani

Kids these days! There they are, creating all their little mobile apps, yet too many of them aren’t considering the possibilities provided by connections to other apps. That, at least, is the view of Cloudbase.io founder Stefano Buliani, whose London-based backend-as-a-service (BaaS) outfit wants to make it easier to both plug in and cash in.

As part of reaching that objective, Cloudbase.io has launched a shared API to encourage data-sharing between apps. By way of example, someone coming up with a Foursquare-like idea could decide to use Cloudbase.io to build their application. Cloudbase.io would handle the backend for that app, and the developer could tell the BaaS provider to let other apps access their shared API, allowing those apps to draw on the app’s check-in data and creating opportunities for business deals down the line.

As Buliani told me:

“What I found everywhere [as I was promoting] Cloudbase.io was that everybody with a background as a backend developer instantly got it. Mobile developers were questioning the need for their application to be connected to the internet. Most mobile developers are only mobile developers; they’ve never done anything else before – never worked on websites, for example. They had this mentality of building the small game for mobile.

“The premise for the idea is that we want mobile applications to become platforms. We want them to be able to publish their own layer of APIs, even though it’s hosted on Cloudbase.io. Cloudbase.io becomes invisible in the background. We want to encourage them to be as ambitious as possible and think of themselves as a platform. It’s a chicken-and-egg game of course – what came first, the business or the API? – but we want them to be prepared for it.”

This perspective is unsurprising coming from Buliani, a developer (he was part of the early Covestor team) who became a management consultant in London’s financial heart before returning to tech. But then again, Cloudbase.io is not the only company trying to help smalltime developers think bigger.

So what about rivals such as Parse? According to Buliani, there’s a “philosophical difference” between the two outfits.

“The easiest example is, if you want to build an application on top of Parse you have to register the users of your application within that framework, so your application will have to have authentication. With Cloudbase.io you can have no authentication — it’s entirely up to you,” he said, adding that he was proud of the fact that all of Cloudbase.io’s libraries are open source and available on Github.

Of course, Cloudbase.io’s new service also crosses over somewhat with the territory of API management specialists such as Apigee and 3scale.

Cloudbase.ioAs with Parse, it’s free to register with Cloudbase.io and get going. Once the app’s in an app store, users need to start paying – the most basic account costs $11.99 a month, which comes with a gigabyte of data exchange. Above that are professional ($47.99 for 8GB) and enterprise ($119.99 for 20GB) tiers, with the possibility of negotiated pricing for higher volumes.

Users should take note of how data exchange volume pricing works with the shared API. If the app accessing data from the original, Cloudbase.io-using app is also using the same BaaS platform, it’s that second app that gets charged. If the second app is off-platform, it will obviously be the original app’s developers who get charged (it might be smart to publish the shared API but keep it password protected).

Incidentally, for those developers who need as much help as possible, Cloudbase.io also partnered up last month with MoSync, a provider of open-source tools for building mobile applications. The idea there is for MoSync to allow the building and compiling of the apps, with Cloudbase.io adding in the connectivity, geo-location and social pieces.

(And on another note, cloud infrastructure and data-sharing will definitely be on the agenda for discussion at our Structure:Europe conference, which will run in London on September 18-19.)

You’re subscribed! If you like, you can update your settings

  1. Mobile app development has ballooned into a stratified industry and is getting bigger every day because of the speed of smart phone adoption. As mobile becomes a more standardised part of our lives, the market will only get bigger and more demanding for developers. So it’s important for developers to start recognising that this isn’t a one man show anymore.

  2. Mobile app development has ballooned into a stratified industry and is getting bigger every day because of the speed of smart phone adoption. As mobile becomes a more standardised part of our lives, the market will only get bigger and more demanding for developers. So it’s important for developers to start recognising that this isn’t a one man show anymore.

    Developers lives get easier with companies like Cloudbase and MoSync who almost serve as quality control because they make sure that developers are focusing on ideas. However, do developers like this?

    Especially with newbie’s like PlumFare who use user generated mobile app data to drive retail purchase. Here’s how it works – a diner takes a photo, their friend sends them a gift voucher for that eatery, the app gets a kick back from the retailer, the retailer collects valuable data and both customers (app user and gift receiver) are happy.

    As a marketer, companies like Cloudbase are taking giant steps to help monetise the mobile game. How are developers responding? Is the expansion of their industry and mobile market what they want?

    1. Hi Shelly,

      As I mentioned in the interview it has been a process. Some mobile developers initially struggled with the idea of their app using data from the internet and connecting their users. Once that idea is accepted the step from connected-app to a service like cloudbase.io is small.

      We have seen an incredible uptake since last december and more and more developers have started building applications that utilise some form of cloud infrastructure. According to a Gartner report by 2016 40% of all mobile applications will leverage some form of cloud backend (http://mspmentor.net/cloud-computing/cloud-mobile-back-end-services-offerings-msps-gartner-suggests)

      We now want developers to take the next step in this process. Start building their application as a lasting business, not an app that will appear on the store and be forgotten in a few months. We want them to be ambitious and turn their app into an online business.

      Stefano

  3. The aspect that seems to be missing from this is data privacy and protection.

    As a user I don’t want my data being shared with another application with which I haven’t agreed to a sharing arrangement. Of course we can point this out through T&C’s, but more importantly how do we make clear to a consumer that whatever they store on one app is going to end up elsewhere? How do I as a consumer make sure that the friend list I have on a photo sharing app doesn’t get transferred to a adult dating app without my consent?

    At the moment it feels like this is the elephant in the room, we’re focusing on developers building cool apps, but if we don’t protect user data then there will be legal and commercial fallout.

    By the way, I don’t think that the lack of authentication is a selling point, encryption and securing my data is a big deal. A platform that allows developers to play fast and loose in not ideal.

    1. Hi Paul,

      The data is kept by cloudbase.io on secure servers and legally is owned by the developer of the application. Cloudbase.io cannot access it and the agreement is entirely between the developer of the application and the end user.

      Of course we will take any report of an application mis-using its users data very seriously – If an app is found in breach of its contract with its users then we will block it until the situation is resolved.

      Cloudbase.io does support authentication – However it is up to the app developer to use it. While it is a great way to protect users’ data many applications are very simple games, they only want a username to identify their users and do not collect any sensitive data about them. Adding a registration and login screen to these apps just adds an additional barrier for the developer to acquire a user.

      The bottom line is that cloudbase.io leaves this choice entirely up to the developer. The app’s data is protected regardless using the unique credentials the developer has to provide to be able to connect to the service. Nothing is entirely open.

      Hope this answers some of your questions.

      Stefano

      1. Hi Stafano,

        That wasn’t really my point, so apologies if I wasn’t clear. I was trying to theorise around the situation you presented where an app can make user data available to another app through APIs:

        “Cloudbase.io would handle the backend for that app, and the developer could tell the BaaS provider to let other apps access their shared API,”

        So how as a user do I prevent that happening? WiIl it really be in the T&Cs, or will apps have to be
        more blatant in telling users that they will share their data with other apps.

        An app might secure my name and address, but if it shares my location checkins, then how hard is it to work out where someone lives and works? Connect it with another app that shares purchases or comments on photos and you’re starting to build up some strong connections that the user may not have anticipated when they signed up. Of course that happens today on the web, but I think there will be a backlash at some point.

        As for the authentication issue, it was really not whether you supported it, it was whether you enforced it. I would prefer it to be the latter. What looks like harmless data can be combined with other harmless data to build up a personal picture of someone.

        1. Hi Paul,

          The Shared API can be password protected. Developers will only give access to them to other apps they have an agreement with.

          In this case we act as a hosting provider, we do not own the data or police it until we receive a complaint. The agreement is entirely between the app developer and their users. I can promise you we will take any complaint very seriously.

          We had a discussion with our users about authentication and an overwhelming majority was against the enforcement simply because they did not collect any sensitive information other than a unique username, their concern was the additional barrier to entry for their users if they had to enforce registration/auth.

          Stefano

        2. An additional note Paul is that developers will have complete control over what is shared.

          A Shared API is a function (a bit of code) they write to return data. For example if they have a collection in their cloud database containing user details they can decide to publish a Shared API returning only the first name.

          In this fashion they could decide to implement an additional layer of authentication within their Shared API and handle it themselves.

          Our entire philosophy is to give them the flexibility and power to do whatever they want/need within the boundaries of reason.

  4. I’ve been keeping an eye on cloud base, it’s a very interesting player in the market. I like their flexible approach, not tying you into a particular framework, which is different, in a good way, from a lot of the other backend as a service players. It’s good to see the service gaining traction and getting more attention.

    1. Stefano Buliani Andy Wednesday, May 22, 2013

      Thanks Andy, much appreciated! We look forward to hosting your next app, and platform!

  5. I guess app developers using this would still have to make sure that
    their data sharing abides by data protection laws, but as a user I’d
    still be slightly worried what forms this might take.

    That said, say an iPad app that I also have an Android version on my
    phone of could easily share and sync data over such a service which is
    nice and not happening often enough yet cross-platform.

    As for different apps sharing data I wonder what form this can take.
    As long as it’s apps A and B sharing data with the requirement that
    app authors agree and individually hardcode their sharing and data
    structures, well that’s useful, but the real potential has got to be
    standardised bundles of data that large numbers of apps can tap into.
    The obvious thing would be contact data (with indeed privacy
    concerns). I wonder what else might fall into this category.

    1. Hi Thomanski,

      If your app is running on multiple platforms you have nothing to worry about. Once you have registered your application with cloudbase.io you will have access to the same database with all helper classes by initialising them with your applications credentials. That’s covered.

      As for the sharing of data between applications you have got it exactly right. It is not a matter of forms but it is all up to the terms & conditions between the application (its developer) and its users. We are simply a hosting provider in this case and offer all of the possible security settings to developers to prevent unauthorised access to their Shared API. It is then up to the developer to publish & receive data accordingly to the terms it has set for their users.

      We will police it if we are notified of an infringement. We will do our utmost to double-check Shared API before they are published. At the same time, we want to leave as much control as possible with the developer.

  6. Many people want mobile apps but think it is too hard to create them. Fortunately now there are quite a lot of useful online services which allow building apps without programming skills and in hours. I am using SnAPPii at the moment and really glad I can feel like a mobile app developer and make apps on my own. Both native and HTML5 apps can be created.

Comments have been disabled for this post