How We Do Cloud APIs and BYO-Back End

During any software development project, pivots are made. Sometimes these are relatively minor, and sometimes they are fundamental changes to a product roadmap. One big pivot we’ve made at Dropsource is to change how we work with back ends and cloud API’s. For most mobile development projects today, integrating with cloud services is an absolute must. Accordingly, we transitioned away from building custom back ends in Dropsource to allowing users the ability to integrate their own back ends and/or 3rd party cloud API’s into Dropsource apps.

At first, we envisioned Dropsource automating the development of an app’s web service. We did this by generating a REST API with standard CRUD endpoints for the data objects specified within an app. This design allowed us to automate a lot of the decisions and work that a developer had to do, such as database creation, implementing an authentication and authorization scheme, server setup, framework selection, and other tasks.

This concept worked well and allowed users to quickly build basic apps with simple data sets. Despite this early success, we quickly realized that in order for our users to build production quality applications, we needed to provide a way to integrate existing cloud APIs into Dropsource apps. Ultimately, we found that our initial users were not getting the full value of Dropsource without the ability to implement custom server-side business logic, use the back-end language of their choice, and make full use of existing APIs.

That being said, we have made the conscious decision to move Dropsource in a direction that focuses on interoperability. Feedback from initial user testing combined with studying the way Dropsource has evolved throughout the development process made us realize that we could provide a lot of value by using existing tools and design patterns to build integrations with existing APIs into Dropsource.

BYO Back End

Dropsource gives you the power to include any data you want in your apps, as long as it is driven by an API that meets a few basic requirements. Although our goal is to eventually be agnostic to API design, there are a few requirements an API must meet before it can be Dropsource compatible (for the time being).

APIs must:

• be RESTful
• support JSON
• if using protected services, follow one of these authentication schemes:
  1) Basic Auth
  2) OAuth2 (password & implicit flow)
  3) API Key
• have logical status code responses

Swagger

With the decision to allow users to integrate existing cloud API’s into Dropsource, we had to decide which format users would employ to communicate the structure of their API to Dropsource.

Recently, there has been an emergence of a few popular API documentation tools that aim to make APIs consumable by both humans and machines. Some of the most prevalent being Swagger, RAML, and API Blueprint. After investigating the pros and cons of each, we decided to initially support Swagger integration due to its extensive community support and the variety of open source tools that integrate with it.

Here is a link to learn about Swagger and its awesomeness: http://swagger.io/specification/

Put simply, Swagger works by allowing a developer to document everything about their API in JSON or YAML (paths, parameters, authentication schemes, protocols, data model definitions, response and body definitions, and API meta information). Once all of this information is documented, Dropsource can learn about your API and make all the relevant options available on the Workbench, our visual development environment, so that you can easily connect your app’s interface to the API endpoints.

Swagger also provides its own great testing environment and already has hundreds of APIs documented and several communities dedicated to sharing user-built Swagger specs for popular APIs. Now, the same model that is used for connecting your custom API also works for integrating third-party services such as Facebook, Twitter, Salesforce, ESPN, and countless others.

A Better Way, More To Come

We really like Swagger, but not to rest on our laurels, we are still exploring the option to add support for other documentation formats down the line that can be read into Dropsource (e.g., API Blueprint, RAML, etc.).

Building a framework for integrating APIs into Dropsource will also give us the ability to integrate with existing BaaS providers. Although we do not currently support this, we are investigating potential partnerships that make sense for Dropsource users, all in an effort to make apps built on our platform more valuable.

We’d love to hear what you think about our approach or your experience with integrating custom web services into your mobile apps. Please comment below, or reach out to us on Twitter @Dropsource.

☞ Please tap or click “♥︎” to help to promote this piece to others.

Check out Dropsource for your next app development project. Our platform helps dev teams efficiently build & ship quality native apps by converting your team’s app designs into concise, extendable native source code.