DISCLAIMER: I wrote the first draft of this post 9 months ago. I only finished it now because I was very
BaaS and Parse have certainly evolved since them and although I believe everything in this post still holds, some details might be outdated. Feel free to correct me in the comments if you spot one.
(m)BaaS looks cool. Very cloudy, or whatever. So when we had the opportunity to use Parse for a real customer project, we took it. The backend was simple enough. The load was going to be high. It looked like a perfect match. Yet it wasn’t. It was a mistake, one I won’t make again. Here is why.
There is always that one feature
Whatever provider you use, unless it is fully customisable, you are always going to miss one feature. It might be something unimportant. It might be something small. But it will probably be a big pain in the ass.
For us, the feature was IP detection. The use case was incredibly simple: users could do some actions without registering, but were then identify by their IP. I know it may sound like a bad idea and I would generally agree, but in this case it was simply the best – and only good – solution.
Parse doesn’t support that. Something that would have been incredibly easy using Rails, Node.js or even freaking PHP is just not possible. We had to resort to using a less than good solution, because when you are facing such a missing feature in a BaaS, there is no way around it. You cannot add it yourself, no matter your expertise and the time you are willing to put on it. It is not possible, move along.
When something goes wrong, you are powerless
At some point during development, I started getting weird errors. Apparently the database was taking too long to respond and the server called timeout. I asked support and found a similar issue, but it took a while being fixed.
The real issue here is not that there was some problem at some point — that is bound to happen in any software project — but that when it happens, you are completely dependent on the willingness of the provider to fix it. You do not control the priority of the issue, the manpower assign to it, and you certainly cannot do anything to fix it yourself. You are thrusting someone else with your entire backend, including your data, and should they fail, so will you.
You are locked in
I always find it hard to argue about lock-in without sounding like a free software extremist. After all, the cloud is synonymous of less control for more convenience, and I am usually fine with that. BaaS vendors will always repeat ad nauseam that you are not locked in, because you are free to take your data and go whenever you want.
First of all, being free to export all your data seems obvious and doesn’t make a convincing argument. It also ignores one important fact: whatever the format in which you can get your precious data back, it won’t be exactly as you need it to be imported elsewhere. There will be work to re-arrange it, and that is part of the leave cost.
Second and most importantly, should you choose to leave, you can pretty much throw your code in the trash. Not only the custom backend code but also your front-end code will be closely linked to the BaaS you were using, with all their libs and frameworks that made your job so easy. So yes, you can expect to rewrite pretty much everything that made your app outside of CSS.
When we went back to Rails
As I said, one of the reason we chose Parse for this particular project was the expected load. The customer estimated 100,000 visitors per hour during a few hours of runtime. This was not a load we felt comfortable handling ourselves, but surely Parse could handle it. We felt we required around 100 requests per second, which is a little more than twice the basic limit, so surely we could figure something out with their Enterprise sales team. We were wrong.
A salesman responded with an offer: an Enterprise Plan running at $12,000/year. No monthly plan. No SLA. 400 requests per seconds. More than we needed, but not at all what we asked for. And for 12 times the amount we had in mind.
And so we were stuck: our only choices were to leave the limit and make our users suffer, pay a ridiculous amount of money for an app that was going to be live for a few hours, or re-write the whole damn thing.
In the end, we chose to re-write the entire backend in Rails, and change the front-end accordingly. And that is the last time I will ever use BaaS.