Thin layer BaaS

May it rest-in-peace!

I worked with one backend-as-a-service (BaaS) provider, Quickblox, where I saw closely users vetting the provider for stability and scalability (successfully). And I followed the rise, sale & fall of another, Parse, where we’re all seeing the impact of it’s folding on a wider community of users.

Combining experiences from both, there’s a business idea ringing in my head:

A thin-layer BaaS

What’s that, you ask?

Basically a BaaS that’s just a thin processing layer between developers and the actual BaaS.

The service provides a standard API set, probably based on that of Parse – given that it was the most used, and is now open source.

The thin-layer BaaS converts developer requests made to it’s own API, into requests to actual BaaS providers – be it OSS Parse, Kinvey, Quickblox, Appcelerator, Amazon, Google Cloud, or others.


It provides a layer of standardisation – with accompanying safety, ease and simplicity – over the BaaS vendors’ disparate APIs, IPs, and end points.

So that if the developers decide to switch vendors – because they’re unsatisfied, upgrading, or because the vendor went KIA – they can do so without having to change the production code in apps/services.

Just login to your thin-layer BaaS account, and provide new vendor auth details.

Anything else?

Just one more thing.

Having a thin, intermediation layer could also help developers spread the backend across multiple BaaS providers – by user groups, features, etc (e.g. Quickblox for chat, Amazon for image storage, Kinvey for rest). Again, without breaking/changing production code.

And this is just off the top of head of someone who isn’t even a backend developer. A bit of further thought, and effort, and this should be a quickly executable offering.

Hang on…

Am I not just adding yet another layer, i.e. yet another point of failure / down time?


The (slightly) bright side is that a thin client isn’t storing or processing any data. The primary cost is bandwidth – moving incoming requests to BaaS, and returned data to clients. This reduces costs.

Lower costs may result in a lower burn rate, and thus a smaller chance of going belly up.

What next?

This is, what I call, an Open Source Idea. Feel free to go ahead and use it to do whatever you want. Keep me in the loop, if you want. Or not. Just try, to not do evil.

If you want it to make it with me, ping me.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.