Content uploaded by Brian Carter
Author content
All content in this area was uploaded by Brian Carter on Mar 22, 2017
Content may be subject to copyright.
This work was supported by Chippewa Software Technology Brian Carter is with Chippewa Software Technology, La Grange, KY 40031
USA (e-mail: briancarter@chipsofttech.com).
Abstract In this paper, the concepts of growing your own
Backend-as-a-Service (BaaS) platform using vendor agnostic
concepts are explored. The proposal is to define, architect, and
design a heterogeneous micro-applications based platform. The
BaaS platform is a critical business resource and growing your
own is required to avoid vendor lock-in, platform shutdown/sun-
setting/retirement, or any adverse changes.
An introduction is given on the concepts of BaaS. A short
overview about the current state of research and existing solutions
is provided. To set the scope, application requirements are
documented. The micro-application BaaS architecture and design
is given at the conceptual level to allow for implementations using
current or future tooling. Details are discussed on how to
implement the platform. We conclude with the future state for
BaaS platforms.
Keywords:API; Application Programming Interface; architecture;
BaaS; Backend-as-a-Service; cloud computing; heterogeneous;
service; mongodb; mongoose; nodejs; platform; service oriented
architecture; SOA; software; web services;
I. INTRODUCTION
This is an exciting time to be a developer, the services that
we have access to and the tools we develop with are really
state of the art. The only thing limiting what we can do in an
app is our imagination. It truly is a great time to be building
the next big app idea. The space is growing and technology is
advancing to enable us to do more with less, at large scale.
We have a low entry into mobile, web, cloud, wearable
devices, and Internet of things to implement our ideas.
Do you as an app developer just tend to focus on your app
and making the experience as great as possible? You tend not
to think about the database, servers, replication, scaling,
notifications, logging, Backend-as-
a-Service (BaaS) is the perfect technology for you to power
your apps [1]. Focus on making your user experience great
and outsource the redundant backend tasks.
outsourcing the infrastructure,
platforms, software, and the backend as a services (i.e., IaaS,
PaaS, SaaS, BaaS) has had a profound impact on the speed to
market, user experience, affordability, and availability of
creating the next big app. Like all mem
family, BaaS builds on the concept that the product
can be provided on demand. The need for storing data,
analytics, push notifications, photo uploads, and many other
service offerings can be centralized and outsourced to a BaaS
platform. For app developers, we can focus on building the
next big app.
The goal of the BaaS platform is to help businesses solve
their backend dilemmas. As more and more developers and
companies realize the worth of implementing BaaS (saves
time, eliminate redundant server and stack setup for each app,
eliminate boilerplate code, brand awareness, fosters open
innovation, increases efficiency, richer app, cross app
advertisement-marketing-profiling-personalization,
services will emerge on the BaaS platforms [1, 2].
With all the service offerings provide by the BaaS platform
to all your apps, it quickly becomes a mission critical business
resource. Ownership is key. Ownership of the BaaS platform
is required to avoid platform shutdown/sun-setting/retirement,
vendor lock-in, or adverse changes. While there are many
safe? Many proprietary platforms have shutdown
PayPal
and many more). Notices received like (1) and (2) have left
many businesses questioning their future and how to move
their apps off the closed platforms.
ave a difficult announcement to make.
Beginning today we're winding down the Parse
service, and Parse will be fully retired after a year-
Kevin
Lacker, Co-founder of Parse [3] (1)
customers can export their data until
March 31, 2014, after which point data will no longer
be accessible. A data- [4] (2)
The concept of a BaaS is rock solid and worth
implementing strategies to support the emerging services [5].
The Backend as a Service (BaaS) market is projected to be
worth of over $28 billion by 2020 [6].
your BaaS to protect your business and applications.
Our argument in this paper is for you to grow your own
BaaS. We will explore what is required, how the architecture
and design is constructed, and how you would build it. Many
advantages, you have (ideally own) the source code, you build
what you need at the time, and you grow your platform for
your needs. Take full control of your critical business asset.
II. RESEARCH
-a-Service waters can be a choppy
adventure. Different service flavors exist up and down the
entire technology spectrum, starting as low as Infrastructure as
a Service (IaaS) access to physical hardware Platform as
a Service (PaaS) infrastructure and platform taken care of,
just build or bring your own app like AWS or Azure all
the way up to Software as a Service (SaaS) like Salesforce,
Office 365, and Gmail.
BaaS
offerings. At its core, BaaS platforms enable you to store your
data without the headaches and cost of developing and
maintaining unique services for each application. A BaaS
couples a basic data store with expressive user provisioning
and authentication tools. As an app developer, think of it like
Brian Carter, Chippewa Software Technology
2
a NoSQL database someone else manages for you off in the
cloud, except that access is via a REST API. Cloud-based
storage is just the beginning of a BaaS offering. Which BaaS
is right for you s look at the most commonly used
service offerings:
Storage: Every BaaS provider will offer some kind of data
storage. Some will offer schema-less and others more
structured abilities. Storage of any type of data will be
managed using APIs. The ability to query, sort, page, and
filter is required. More advanced features might include data
connectors to sync cloud-based data to other on premise data
stores.
Dashboard: The ability to manage your data and users
through some sort of portal is important. While all the
services can be performed via APIs, having a UI is often time
saving and informative. The option to manage data, services,
users, authorization, and to view reports is a nice feature.
User Administration: User provisioning and authentication:
important in most apps since apps need to limit who can
access what data and services are available. A common
example is a doctor should only have access to his or her
patients, not every patient in the application. A BaaS allows
you to configure "groups" of users and then determine what
data they should be able to access through Access Control
Lists (ACLs). Platforms need role-based user permissions and
granular claims-based permissions. Also, 3rd party
authentication with sites like Facebook, Twitter, Goggle, and
others is helpful.
Analytics: The ability to track API calls is important. This
gives you a view on who, when, and how often someone is
using your BaaS. Having the ability to track performance,
errors, events, and storage usage is important. Personalization
for your users will deliver a better user experience.
More: There are many other services that can be added or
included to a BaaS. This might include the need for:
Push notifications
Social integration
Personalization
File, photos, & assets management
Geolocation
Multiple Mobile Platform SDKs
Custom code Integration
Background Jobs
Configuration
The list of service offerings should provide you with what a
BaaS platform could offer. This list is growing and more
redundant tasks are getting added. Think of the service
offerings you add in each app, that require custom coding and
maintenance, moving the repetitive functionality to a common
backend platform makes sense. There are hundreds of options
for BaaS platforms and the list is growing quickly [7].
Reading through the list, it ranges from general purpose
providers to specific offerings. A growing trend is a move
away from monolithic platforms to more specific platforms
based on need. Decoupling the monolith into individual
offerings allow for finer grain sections and allowing for cross
vendor selections.
There are many open-source solutions in the list. When you
-source
platforms to see how they implement the offerings you are
looking for. It is recommended that you fork any open-source
you are researching. Having your own copy of the code is
critical, especially if you use it for your next app. Certainly
open-source projects implode as well, but rarely with the scale
of things like Parse. Make sure you have full open source
access, the ability to run your own server, and an active
community development and maturity (avoid risk of
abandonment if creators lose interest). An option for growing
your own BaaS is through the use of open source projects.
Choose an open source BaaS, choose open source libraries, or
III. REQUIREMENTS
As we saw, BaaS platforms come and go. Even very large
platforms have been shut down. In my option, growing your
own has many advantages. The top being the learning and
knowledge of the workings. Build it for your needs, leverage
open source libraries when needed, and leverage other open
from most).
There are things you must be aware of before heading down
this path. If following are true, then growing your own is the
way to go.
Do you have the time, skills, and resources necessary to pull
this option off?
Do you need to have more control over code, reliability,
performance, features, and costs?
With this being true, l me time to think about our
needs. For this paper, the goal is to introduce BaaS and show
how you would grow your own. To keep things simple and
clear, the first release will be constrained to include just the
storage offering discussed in the previous section. For our first
release, v1, we will include:
1. Name
2. The ability to create new databases and collections
3. An API to perform Create, Read, Update, and Delete
(CRUD) operations on the data.
4. The ability to query, sort, filter, and page the data.
As you can see from the v1 release, this is the core of the data
service for storage. Building our release roadmap, we will work
through the service offerings listed in the previous section as
needed for apps we are building. No sense adding in offerings
r see a need for (unlike closed platforms where
Additional papers and
tutorials will be presented as we build Pondwater and our next
3
big apps. Pondwater is open source so you can follow our
progress on GitHub [8]. Yes, use it as is or take parts that you
need. Even better, contribute where you can.
IV. ARCHITECTURE AND DESIGN
A great architecture encourages developers to use it and
share it with others, creating a virtuous cycle where each
additional successful implementation leads to greater
engagement and more contributions from developers who add
value to your application. To accomplish this goal, the
architecture and methodology focuses on:
o Simplicity: A consistent and modular architecture
o Flexibility: Change and add service offerings quickly
o Extensibility: Easy to add new service offerings without
impacts to other offerings and the platform.
The foundation for the architecture is based on the concepts
of growing heterogeneous Micro-Applications by incremental
development [9] as shown in Fig. 1. This fits well with our
requirements for the BaaS will be grown in increments based
on the need. This keeps the architecture and budget lean. With
this strategy, each service offering will be a micro-application.
This will allow each application to adapt to new and changing
business needs independent of vendor. This also positions for
the use of and inclusion of other micro-applications that extend
or replace platform offerings. For example, the dashboard
offering (micro-app) will change at a faster rate than others due
to the rapid changing user interface designs and technologies.
The platform acts as the gateway and can support multiple
dashboard offerings. The platform has the ability to phase in
such offerings. Together, this allows for a better adaption and
transition when there is change.
To accomplish the above goals, the platform is built around
a layered, modular architecture. But, what does that really mean
you might ask? It means that individual pieces of functionality
are self-contained: the storage offering and its components
should just be built for storage, not a sprawling monolith of
other functionality, and should be portable between other BaaS
solutions with a minimum of dependencies.
developing micro-apps that you would like exposed across
multiple areas of the platform added to the
platform layer. The platform will proxy and route the request
to the new offering. This provides a layer of protection so
future changes can be transparent to the calling application.
The architecture for our BaaS Platform is an API first design
following the beyond twelve-factor application principles [10].
Consuming applications have access to a powerful, cloud-based
Backend-as-a-Service (BaaS) platform that provides the apps
with easy to implement service offerings via a RESTful API.
The platform is the API gateway for all requests and can have
one or more service offerings. Each service offering is built
following the micro-application principles [9]. Each app is
built on a software development stack chosen by the product
team (the team building the app). There is an Object Data
Manager (ODM) to communicate to the data store. As with any
application, the micro-applications can leverage the service
offerings of other micro-applications. This dependency is done
in a hierarchy pattern to avoid circular coupling and
dependencies. For example, the storage offering will be used
by other offerings, so it is at the bottom of the dependency tree.
V. IMPLEMENTATION DETAILS
The goal of the framework is to abstract the details of
)
from the consumers. The consuming application only need to
know the APIs and what resources are available. An API
represents a contract between the service and those who
consume the service. Building an API is one of the most
important tasks. By having a simple API, the BaaS has the
potential to become a platform from which other services will
grow and other applications will use.
This starts with the implementation of the platform. The
platform is an API gateway that coordinates the requests to the
micro-applications and the returning responses. The gateway
is very light weight and its main responsibility is to route traffic.
If features are required, the platform should use micro-apps, for
such things as access control, rate limits, usage policies,
analytics, monitoring, logging, and management. In
Pondwater, we grow our own platform API gateway to include
some of the key most basic features often needed for API
management [11].
The implementation of the micro-apps follows a RESTful
API design. The consumer, a client application capable of
making HTTP requests, interact with platform via APIs. The
HTTP protocol is used for communication over a network. The
platform defines endpoints, API URLs on the server that
represents the services provided and what resources are
available. The platforms API gateway calls the corresponding
micro-application.
Standard Verbs are used for request. The URI for the API is
Figure 1: conceptual level BaaS architecture.
4
based on the service offering. The verb GET retrieves a specific
resource from the server. The POST verb creates a new
resource on the server while the PUT verb updates the resource.
DELETE removes a resource. The pattern for verbs and URI
stems is shown in Table 1 along with examples for the storage
offering. The pattern includes the service offering, the version,
and the requested resource.
The following GET storage example returns the documents
in the soccer collection:
/store/v1/soccer/players
In example (3) for a GET, the URI parameters would get the set
of documents where the jersey is greater than 0, only the jersey-
name-email fields, it would be sorted by jersey skipping none
and only returning at most 6 documents.
query={"jersey": {"$gt": 0}},
fields={"jersey":1, "name": 1,"email":1},
sort={"jersey": 1},
skip=0,
limit=6 (3)
As shown in the API pattern, versioning is an important
implementation detail. The URI is formed by api/:service-
offering/:version/:service-specifics. If you are simply adding
new features to your API, such as a new attribute on a resource
or new endpoints, you do not need to increment your API
version number since the changes do not break backwards
compatibility. Over time, the need to break a contract will be
required. The API design allows for and tracks multiple
versions of the service offering by placing the version in a URL
segment. This will allow consumers to consume the newer
version when they are ready. Older versions will be
depreciated. The version is by service offering. This allows for
each offering to be added or updated based on its schedule. It
also minimizes impacts and coupling, by only impacting the
consumer based on a specific offering and not the entire
platform. This gives the consumer more options, to consume
some updates quicker and others based on need and schedule.
The response is a critical implementation detail. Each
resource returned by an API must have resource attributes
defined. The exact metadata for the attributes depends on the
platform and service offering. For the developer, knowing the
details about the data return is critical.
implementation, the response has platform details and service
offering details. For the storage example (4) is
defined an
version and resource is echoed back which is helpful for tracing.
Specific for the storage offering, it echoes back the query,
fields, sort, and skip values received. The limit value is echoed
back or set by the micro-app if such limits are set or exceeded.
The total number of items of items in the set is returned to aide
documents. Each document has an id that uniquely
identifies it. Example (4) shows the response for v1 of the
storage offering.
{
"platform": {
"type": "store",
"version": "v1",
"resource": "soccer/players"
},
"query": {"jersey": {"$gt": 0}},
"fields": {"jersey": 1,"name": 1,"email": 1},
"sort": {"jersey": 1},
"skip": 0,
"limit": 6,
"total": 1,
"items": [
{
"_id": "5807c471cb1d53801a000002",
"name": "Brian Carter",
"email": "briancarter@chipsofttech.com",
"jersey": 1
}
]
} (4)
As with typical data applications, the storage solution adds
fields to the document in storage for POSTS and PUTS. A
feature of the storage solution is the ability to have data in a
published. When the fields are not present represents resources
in a draft state. As a developer, you have full control over the
micro-app so this can be changed based on your specific need.
Whenever something goes wrong with an API request, the
TABLE I
PONDWATER STORAGE VERBS AND URI STEMS
Verb URI Stem
[Pattern] /:service-offering/:version/:resource
POST /store/:db/:collection {JSON data in body}
GET (set) /store/:db/:collection?query,fields,sort,skip,limit
GET (1) /store/:db/:collection/:_id
PUT /store/:db/:collection/:_id {JSON updates in body}
DELETE /store/:db/:collection/:_id
TABLE II
PONDWATER ERROR TYPES
Status
Code Error Code Description
400 BadRequest Malformed request or missing parms.
400 InvalidQuery Request contained invalid query parms.
401 Unauthorized The authorization was invalid.
403 AccessDenied
Access to a resource denined.
404 NotFound Resource could not be found.
422 ValidationFailed Query references invalid fields or inv
alid
JSON.
429 RateLimitHit Too many requests per second.
500 ServerError Error on server.
5
platform returns an error. An HTTP status code indicates the
error type, with further details in the response body as shown in
Table II. Errors share the same common attributes as other API
generated by Pondwater. A
will have a short description of the error (configurable on level
of detail). The status code is return as the response HTTP status
With the strategy and details defined, there are many options
for developing the platform and micro-applications. The
architecture, design, and implementation details could be
written in any language. For this paper, we implemented
Pondwater using Node.js, Express, and MongoDB. The nice
thing about this development stack, it can run on many different
Meeting our vendor agnostic requirement. Again, this decision
is up to you as a developer and your team as owners.
Pondwater is open source and has an MIT license so you can
use it, help me extend it, or just copy and page the good parts
[8]. Follow our project as we build code, tutorials, and
documentation. The purpose of this paper and the reference
application is to provide you with an introduction and overview
of growing your own BaaS platform and a product to get a
hands on exposure.
VI. FUTURE STATE
When growing a platform, it should be a rule that it will be
heterogeneous. Heterogeneous by default should be a design
and development practice. The computational fields are
growing at a rapid rate and heterogeneous aspects must be
embraced and supported. The rule for growing a platform is
the fact that it will be composed of applications on different
platforms, written in different languages, using different stores,
and running in different processes. This is the future for BaaS
platforms.
Many BaaS platforms owned by the largest companies have
failed and been shut down. Such applications were built as
monoliths and over time could not evolve. For the BaaS
platform to survive, it must evolve to meet the ever change
landscape of Information Technology (IT).
Future service offerings will be introduced. One of the most
exciting features are artificial intelligence and machine
learning. Such offerings are a good BaaS fit due to their
complexity. We are on the cusp of providing large scale, real
value for such technology services. Although computer science
theories and algorithms have existed for some time now, many
of the problems surrounding the implementation have made
them infeasible until the advent of cloud platforms. For many
app developers, home-grown AI solutions are still out of reach.
, AI-BaaS.
VII. CONCLUSION
Often called Backend as a Service, BaaS, an API backend is
a way for developers to link their software and application to
cloud-based services, making it easier to include with software
development kits and APIs. As a developer, you can focus on
making your next great app idea and leave the redundant tasks
to the backend.
One of the main reasons developers are choosing BaaS is
because building your own services takes time and resources,
as processes need to be duplicated and then customized across
various providers. With a consolidated BaaS, you can rapidly
connecting to. API-first movement that allows
everything from website to mobile apps to be built more quickly
on top of an API.
Many like the BaaS approach because it eliminates redundant
stack setup and boilerplate repeat code, and everything is
handled by the platform. However, an
everyone.
it can create bigger security risks.
BaaS is just one of many ways that APIs are changing the
way we develop, design and build great apps. We think the
benefits of BaaS platforms are endless if grown using evolving
architecture, design, and implementation concepts.
REFERENCES
[1] BaaS : Pros and Cons. Retrieved from https://blog.cloudboost.io/baas-
pros-and-cons-4bf0912dead2. October, 2016.
[2] Why You Should Build Apps With An API Backend BaaS. Retrieved
from http://nordicapis.com/why-you-should-build-apps-with-an-api-
backend-baas/. October, 2016.
[3] Moving On. Retrieved from
http://blog.parse.com/announcements/moving-on/. October, 2016.
[4] PayPal closing down backend service StackMob mere months after
buying it. Retrieved from http://venturebeat.com/2014/02/12/paypal-
closing-down-backend-service-stackmob-months-after-buying-it/.
October, 2016.
[5] Big Data-As-A-Service Is Next Big Thing. Retrieved from
http://www.forbes.com/sites/bernardmarr/2015/04/27/big-data-as-a-
service-is-next-big-thing/2/#2f3eb0f76efe. October, 2016.
[6] Backend as a Service (BaaS) Market worth 28.10 Billion USD By 2020.
Retrieved from
http://www.marketsandmarkets.com/PressReleases/baas.asp. October,
2016.
[7] A collaborative list of Parse alternative backend service providers. .
Retrieved from https://github.com/relatedcode/ParseAlternatives.
October, 2016.
[8] Pondwater. Retrieved from https://github.com/ChipSoftTech/pondwater.
October, 2016.
[9] B. Carter, "Growing Software Applications by Incremental Development
of Heterogeneous Micro-Applications Using Cellular Regeneration
Concepts," 2015 Annual Global Online Conference on Information and
Computer Technology (GOCICT), Louisville, KY, 2015, pp. 1-5.
[10] Beyond the Twelve-Factor App
https://pivotal.io/beyond-the-twelve-factor-app. October, 2016.
[11] Building Great APIs (Part III) The need for API Management and
Infrastructure. Retrieved from https://www.3scale.net/2013/10/great-
apis-need-api-mngmt-part-iii/. October, 2016.
