Face it, Backend-as-a-service (BaaS) as a concept is here to stay. It became popular with Facebook’s Parse, which provided a backend platform for developers to rapidly prototype. In reality, developers built full products that from small APIs and games that earned spare change to full-on e-commerce sites such as Myntra. Everyone also knows the chaos Facebook caused when it announced the Parse shutdown (and no, Parse.org is…just, no). Apps disappeared and successful businesses spent months rebuilding their backends from scratch or migrating to other serverless platforms.
Skeptics will always remember Parse as the example of why BaaS can’t work. BaaS isn’t scalable; it’s only for prototyping; you’re always going to be dependent on the provider; it creates spaghetti code. Yes, they’re right – mostly. These concerns are not the whole story. Below, we’re tackling 3 of the most common myths about BaaS so you can make an informed decision about whether it’s the right thing for your product (or your client’s product).
Myth 1: BaaS is not scalable. It is only for prototyping.
This myth came about thanks to the success of Parse. Facebook’s original Parse.com marketed itself as a quick prototyping tool and was not designed to scale (see example below). Parse.com was also expensive. 300-1000 requests per minute costed USD1000/month.
Oursky had a client that wanted to release a product quickly, so we prototyped with Parse.com. Our prototype used NoSQL (more on that later). The product was essentially a chat room for gamers. However, the paid Parse backend couldn’t handle concurrent traffic and latency fell significantly after 300 users (even with the most expensive plan). We couldn’t scale with Parse.com or its open-source successor Parse.org. We switched from an API to a microservice architecture finally. However, the trauma of having to redo everything was horrible. The Crisp team also writes about the nightmare of having to throw out spaghetti code when using a Firebase backend and having to redo everything.
But it doesn’t mean BaaS by default is unscalable. Many other BaaS vendors target enterprise-grade applications and have demonstrated scalable backends. We built Skygear.io with scalability in mind so the app code is always stateless and horizontally scalable; Cloud Functions run as micro-services in Kubernetes clusters, and a database PostgreSQL’s scaling technique is well documented.
|Data Storage||Yes, PostgreSQL with MongoDB-like interface and auto-migration||Yes, MongoDB||Yes, but no direct database access||Yes, but no direct database access|
|Cloud Code||Yes||Yes||Yes (Business Logic Code)||No|
|Real Time||Pubsub and Query subscription||No / Live Query||No||Yes|
|Hosting||Open source deployment / Managed Cloud||Open source deployment||Managed Cloud||Managed Cloud|
|Extend with Plugins||Yes||No||No||with Libraries|
|Platform||Web, Android, iOS and IoT||Web, Android, iOS and IoT||Web, iOS, Android, Windows, REST API||iOS, Android|
|Best for||Web and iOS, Android apps||MVP apps||B2B, B2E Apps||Realtime communication apps|
Myth 2: You have to use a NoSQL database with BaaS
This myth arose because most BaaS choose a NoSQL (MongoDB, Cassandra, or alike) as their database for scalability. Most applications rarely reach the scale where NoSQL databases have a significant advantage over traditional relational databases for scalability and horizontal distribution. Here’s a good overview of the difference between SQL and NoSQL.
Most BaaS providers use NoSQL databases so that you do not have to worry about the schema, making the solution a lot easier for getting started. However, many experienced developers miss the flexibility, structure and optimization that traditional relational databases provide as the application business-logic becomes more complicated.
So Oursky felt it was a good idea to build an open source BaaS with a relational database (PostgreSQL) as the default database. PostgreSQL is a production grade and well-established database (PostgreSQL’s official documentation). Scaling techniques are well known and setting up master slave / read replicas is a common way to scale things up.
There is one thing a document-based database has a strong advantage: prototyping. Not having to define a database schema before development is useful for quick prototyping. For Skygear, Oursky’s open-source serverless backend, we built an SDK that provides a document-like interface for query and storage of data and a backend that automatically handles the migration of a database such as creation of tables and addition of columns in the development environment. It’s like a NoSQL interface but with the SQL backend, thus developers using Skygear do not have to define the schema upfront.
Myth 3: You’ll go down with your BaaS platform.
So after Parse shutdown you’ve probably researched potential successors. You’re even open to changing up your stack. But…how do you know your BaaS of choice isn’t going to get shutdown just like Parse.com? Parse.org was no replacement as it is not even the code from Parse.com. It was just a rewrite and not 100% compatible with the original.
That’s actually one of the reasons one of Oursky’s clients came to us asking for commercial support for Skygear when we had released the Skygear code open-source. Open-source code is transparent, allows the code to be peer-reviewed, and ensures that the backend is independent of the service-providing company. Open-source code is also better in the long-term for security since the developer community can help fix vulnerabilities and prevent backdoors created by a provider. For Skygear’s model, we only charge a client for services such as hosting and maintenance.
A list of BaaS / Serverless providers
There’s always the right tool for the job. Here’s a list of BaaS providers we’ve come across. Some are built for enterprise, others for mobile (mBaas), and some were even industry-specific. Go check out the docs to see if they’re suitable for you!
- AnyPresence – Enterprise
- Kumulos – mBaaS
- Kinvey – mBaaS
- Kii – IoT platform
- Skygear.io (Open-source, developed by Oursky)
Parse was a great start that revolutionised web development and created opportunities for individual developers and companies to create new products based on a shared backend. Even Amazon, which began its AWS as simple cloud functions, is beginning to move into the BaaS space with Lambda. Yes, there’s always a place for your own in-house backend. But no-developer would want to re-invent the wheel for everything from push notifications to CMS. Even if you’re a skeptic, we encourage you to explore the latest options BaaS options out there and keep updated!
Of course, we’d also love your feedback on Skygear. Create your account for free and let us know what you think!