10 ms·

This announcement just underscores the importance of having full control over your backend. Yes, it's more work, but if you're writing apps that seriously depen

This announcement just underscores the importance of having full control over your backend. Yes, it's more work, but if you're writing apps that seriously depend on backend services, it's simply too much risk to depend on anyone else. Fortunately in this case Facebook offered generous lead time to migrate off Parse.com, but they were not obligated to do so, and other providers might not be so generous in the future. Developers who depended on Parse now have an interesting decision to make: export their data into MongoDB and start running their own servers, or look for an alternative BaaS provider to do it for them (which carries the same risk of that provider shutting down in the future).

nawazdhandala 11y ago
... or use an open source BaaS which can be self hosted or managed like CloudBoost.io
- nodamage 11y ago
  Yes, self-hosting falls under "owning your own backend". The managed option carries the same risk of shutdown as with any other provider. I think you can stop spamming your website in this thread now that you've mentioned it a half dozen times though.
intellegacy 11y ago
sigh, I just made my first app on Parse and now I have to migrate to another BaaS. what do you recommend? Firebase? I dont' think running my own servers with Parse is viable as Parse won't be updated from now on while other BaaS will stay updated and keep improving
- asadlionpk 11y ago
  Firebase is good for small hackathon-like projects and it gets ugly when your DB grows. Not much optimizations you can do.
  - mayop100 11y ago
    [Firebase founder here] We'd love to know what limitations you've run into and how we can do better! Send me a tweet: @startupandrew
    - asadlionpk 11y ago
      Well I love Firebase, but to put it naively, Firebase needs more advanced queries. Even more than usual because it is running 'far' from my backend, so queries from backend are expensive. For example, if there was a way to selectively bring back children of an object etc. I know there are workarounds (and I am doing those) but since Firebase is a DBaaS it needs to account for that when compared to other DBs.
      - mayop100 11y ago
        We hear you! And we're working on it.
      - marktangotango 11y ago
        This really seems like a limitation of nosql/mongodb, would it be worthwhile to reconsider sql/nosql trade offs?
        asadlionpk 11y ago
        Well I would say reconsideration is always right but it's expensive (nosql->sql is big deal) when you are a fast-paced startup and don't want to spend resources on non-critical things. I know it will get critical someday, so we are slowly finding a solution to it.
        redwood 11y ago
        Schema design allows you to grab stuff you want joined all at the same time (aka the data lives together in a document) in mongodb's model. This obviously has limitations in many to many relationships where the access pattern isn't clear, but often these tradeoffs can work.
      - 11y ago
jshen 11y ago
"This announcement just underscores the importance of having full control over your backend" I disagree. If using something like this let's you get to market much faster, much cheaper, and find market fit faster/cheaper, then it's worth it. Depending on the need it can take millions of dollars and year(s) of work to then begin working on the actual business objectives.
- nodamage 11y ago
  If you're building a nascent mobile app it probably won't take millions of dollars and year(s) of works to get up and running, regardless of what backend you use. If you do have a project that will take millions of dollars and year(s) of work to get up and running, I'm going to guess you have much bigger problems than what backend you use, and choosing something like Parse won't help you that much.
- jonsterling 11y ago
  We used Parse, and (contrary to your suggestion) it helped us get to market much slower and much more expensively. We experienced a hilarious amount of downtime, and hundreds of engineering hours that could have been spent developing features for our users or improving our services were spent working around fatal bugs in Parse, which were usually not manifesting on all instances, which made it very difficult for the Parse team to diagnose them. Fixes for Parse bugs were usually not forthcoming from the Parse team---and when things were fixed, more often than not the fix was reverted within a week because it caused something even worse. For the first six months of our time using them, Parse would only report downtime post facto and backdated by a day. “F@#$k Parse” was perhaps the most frequently uttered phrase among all of us in our douchebag Mission district headquarters. What a life. All the time, push notifications inexplicably stopped working for hours at a time---we were running a daily sales app, and this really killed us. It ruined dozens of auctions and pissed off tons of our users. But what's even worse? Parse made my life a living hell for a year, and I'm glad they're gone.
  - AlwaysBCoding 11y ago
    It's a good thing they had great documentation... oh wait.
st3v3r 11y ago
No, it just underscores the importance of properly architecting your apps so that they don't directly depend on Parse or others. Keeping that stuff to the periphery of your app will make it much easier to replace when the service either shuts down or you outgrow it.
- nodamage 11y ago
  Eh, regardless of how well your application is architected, it's going to be a pain in the ass to migrate if you have a lot of data/users/versions of your app out in the wild. If you continue to rely on BaaS providers you run the risk of playing perpetual musical chairs as each one shuts down over time. That's not an acceptable level of risk for me, but, to each his own I guess.
rackforms 11y ago
100% agree. Building my first notification-based app right now and Parse seemed like the obvious and best choice. Thing is, after a bit of thinking something felt...off. Not with the service, but off with the idea of attaching this small little project to something so...out of my control. I dug around the net and found a working solution I could install on my own server, and now that's exactly what I've got: The experience of doing this on my own, the flexibility to grow as needed, and the code to implement again and again without needing anyone or anything else. Building apps these days is a massive gamble for small guys like me. We often spend dozens of hours with little to no possibility of return. Any action I can take that reduces stress points and increase my knowledge base, (and this would have been a massive stress point) I'll take.
- geoka9 11y ago
  May I ask what that solution was? :)
  - rackforms 11y ago
    Absolutely! Please do keep in mind no system is perfect, 100% reliability is a dream we all strive to attain, and even with Parse, I've read several reports on this very thread of instances of less than perfect reliability, iffy technical support, and so on. Anecdotal sure, but still. That said: the app sends basic notifications when in-app, user-initiated events of interest occur. The server code is PHP, based off of this fantastic little tutorial: http://www.raywenderlich.com/32963/apple-push-notification-services-in-ios-6-tutorial-part-2 http://www.raywenderlich.com/32963/apple-push-notification-s... I modified and use the code in the simplest possible way: I created the API layer using my wonderful form builder software (https://www.rackforms.com https://www.rackforms.com). Yup, it's form software flexible enough to write endpoints. Check it out : ) The app sends simple GET requests to my server, which are in turn handled by the API job. If a notification is required, the API INSERT's a record into a MySQL table called push_queue. The magic, I suppose, happens with a constantly running PHP script called push.php. This guy's monitored by a simple cron job that checks for its running status every minute. if it's down, cron automatically restarts the script. The notifications are not time-sensitive that 1 minute delays are a deal breaker, and of course any sent during that time are handled automatically when the script restarts. APN Feedback is handled by a second one-the-hour cron job, which calls a simple script called feedback.php. A touch of code was added to deal with the core user's device token being removed for "followers" of that user. Three Key Takeaways: 1. The entire server setup part took me about 5 hours, API code (which we'd need to write regardless) not withstanding. The biggest hurdle was the cron stuff, I shall never forget cron -v cron! Using a third-party service would have been almost the same time, I'd imagine. The best part is future projects will literally be counted in the minutes for start to finish notification server duties. 2. I got to use a language I adore (PHP), and learned a bunch with others I was quite new too (shell scripting, cron, etc). 3. Finally: No app is guaranteed success. I know many of these services have/had! generous free tiers, but after my first app (http://www.skipcast.net http://www.skipcast.net) and its frankly lousy performance, fool me once indeed. If, by some miracle, this new app gains traction, sure, I'll consider a third party. Until then, I'll do it my self thank you very much. In all -- a wonderful experience that I'm keen to tweak and learn more from at deployment time.
snej 11y ago
[Couchbase Lite architect here, so I have skin in this game] Even better, if you're using an open protocol, you can work with _either_ a hosted back-end or one you own, and move between them pretty easily. HTTP being a good example of course. The problem is that open protocols for general purpose data sync are pretty thin on the ground. Couchbase built our sync architecture on top of CouchDB's replication protocol, which was badly documented at the time but at least open. Couchbase Mobile (http://couchbase.com/mobile http://couchbase.com/mobile) uses this open protocol, so you can either BYO server (our own Couchbase Sync Gateway, or CouchDB) or use a hosted one like Cloudant. And you've got full access to the code (ours is all Apache licensed.) I can't say we're directly compatible with Parse, or trivial to migrate to (the data models and APIs are different), and I'm obviously biased, but I do think it's a good alternative to jump ship to.
- pashakym 11y ago
  you better build something quick :) to help all of us (independent developers)
nodamage 11y ago
A few more thoughts: 1. This effectively poisons the well for any other BaaS providers out there. If two of the biggest companies in this space (StackMob and Parse) can get acquired and shut down in less than 5 years, what does that say about the future of the smaller companies in this space? As a developer how could you possibly trust any of these companies going forward, based on this track record? 2. Syncing is notoriously difficult to get right. Building a generalized syncing solution is even harder. Bugs in sync code tend to lead to data loss, which leads to angry customers. These types of bugs are hard enough to track down and fix in your own code. Trying to track down and fix bugs in complex third-party code can be damn near impossible. If you decide to adopt a third party solution that purports to do your syncing for you, do your research carefully. Not just by looking at the toy samples which look easy to set up and work perfectly, but experiences and reports from actual developers who have tried such solutions. What kind of problems are they having? What are the limitations of the current implementation? How mature is the product? How responsive are they to bug reports? If something goes wrong and data is lost, how much insight do you have into the system to figure out why?
- bikamonki 11y ago
  Au contraire: it opens a wider deeper well. Parse customers are now up for grabs. Do you think they will go back to program back-ends and rent a server? I personally won't. So the supermaket chain where you usually shop at closes its stores for whatever reason. Do you go back to farming your backyard or do you find a new store? The BAAS industry is super young, only hipsters are into it. But it makes sense so it will eventually mature. Bugs will be fixed.
  - nodamage 11y ago
    Switching supermarkets is much, much, easier than switching backends. I'm sure lot more BaaS companies will pop up to grab former Parse customers. I'm not sure how many of those will still be around in another 5 years. I strongly suspect there's something negative about the economics of BaaS services that's being implied by the fact that two of the most successful providers have shut down after acquisition.
bikamonki 11y ago
Wrong! Everything we build is on top of layers upon layers and not a single company/IT team has/can fully control all of them! So you suggest: build your own backend API and run it on a VPS/Container/whatever. Do you have full control on the hardware? The virtual machines? The vendor's infrastructure? Let's move a layer up. Do you have full control over the framework you used? The database engine? Does the sum of knowledge/experience in your team guarantees full control on all these layers? Under a security threat who provides the patches? Your team? Do you run your own mail server? Did you code our own OS? This is rethorical of course, all the answers are no. What exactly is wrong about trusting one more layer to 'experts'? Not all dev teams can afford a backend ninja just as they cannot afford a network admin or a telecom engineer. Companies like Parse are on the right track, they provide a much needed service. I've been on this trade long enough to witness the transition of companies hosting webservers in-house to realizing a dedicated server made more sense (one team of experts managing many machines), then VPS, then containers....then BAAS.
- nodamage 11y ago
  Your reductio ad absurdum is not particularly convincing. I draw the line at exactly the BaaS layer specifically because of the high risk of these providers pulling the rug out from under you. If you disagree, fair enough, but I feel pretty bad right now for the poor developer who decided to adopt StackMob, then migrated over to Parse when StackMob shut down, and now has to migrate once again. Fool me once...
  - bikamonki 11y ago
    You'll move that line eventually. Datacenters were a hard problem to solve a decade ago. Now its (almost) trivial. Virtual clouds were a buzzword less than two years ago. Now they are huge and successful businesses. Same path for BAAS.
    - nodamage 11y ago
      That's possible. But the current model of "give us money, use our code, and we'll host your data" is pretty clearly broken.
petke 11y ago
Not to be a dick, but some companies seem to care more than others about the developers that rely on their frameworks. Google doesnt seem to care much. Facebook seems to care more. But Microsoft seems to care most. They have not abandoned legacy mfc, visual basic, and win 32 developers even though they probably should have. Granted those are not services but they require maintenance resources nontheless.
- stickfigure 11y ago
  Eh? I have apps that are almost 10yo on Google App Engine. Even when they forced a complete migration from the Master/Slave datastore to the High Replication Datastore, it was a pushbutton process that required minimal intervention. Honestly if I have any complaint it's that they don't force change faster. On the other hand, Facebook's API changes at a pretty rapid pace and there are few apps older than a couple years that have survived without significant code changes. I've seen API changes that are basically "rewrite your whole app".
s_dev 11y ago
How is this any different to depending on Amazon for your back end?
argo12 11y ago
Developers will now be skeptical about using any BaaS. It can be acquired and shut down. They have every reason to be. We built a BaaS too. It is however built around this core philosophy of developers having complete control over their app backends. Here is the post we wrote about this: https://news.ycombinator.com/item?id=10994104 https://news.ycombinator.com/item?id=10994104
akarve 11y ago
for most applications i hypothesize that the cost of writing and maintaining your own backend will far outstrip the cost of the occasional migration. if anything, the pressure is towards frontend:backend isolation, not away from BaaS. (in the spirit of segment.io for analytics.) one ironic signal here is that money is bad for survivorship. facebook killed parse because it doesn't move the needle for facebook, but parse might have been a fine & profitable standalone business.
Salgat 11y ago
All this underscores is the important of not tightly coupling your codebase to a particular provider.
- nodamage 11y ago
  It doesn't matter how tightly coupled your codebase is. If you have a client app that talks directly to Parse.com, it will stop working a year from now, and you will have orphaned users. Even if you release a new build that points to a new backend, not everyone regularly upgrades, not everyone can upgrade.

nawazdhandala 11y ago

... or use an open source BaaS which can be self hosted or managed like CloudBoost.io

nodamage 11y ago
Yes, self-hosting falls under "owning your own backend". The managed option carries the same risk of shutdown as with any other provider. I think you can stop spamming your website in this thread now that you've mentioned it a half dozen times though.

intellegacy 11y ago

sigh, I just made my first app on Parse and now I have to migrate to another BaaS. what do you recommend? Firebase? I dont' think running my own servers with Parse is viable as Parse won't be updated from now on while other BaaS will stay updated and keep improving

asadlionpk 11y ago
Firebase is good for small hackathon-like projects and it gets ugly when your DB grows. Not much optimizations you can do.
- mayop100 11y ago
  [Firebase founder here] We'd love to know what limitations you've run into and how we can do better! Send me a tweet: @startupandrew
  - asadlionpk 11y ago
    Well I love Firebase, but to put it naively, Firebase needs more advanced queries. Even more than usual because it is running 'far' from my backend, so queries from backend are expensive. For example, if there was a way to selectively bring back children of an object etc. I know there are workarounds (and I am doing those) but since Firebase is a DBaaS it needs to account for that when compared to other DBs.
    - mayop100 11y ago
      We hear you! And we're working on it.
    - marktangotango 11y ago
      This really seems like a limitation of nosql/mongodb, would it be worthwhile to reconsider sql/nosql trade offs?
      - asadlionpk 11y ago
        Well I would say reconsideration is always right but it's expensive (nosql->sql is big deal) when you are a fast-paced startup and don't want to spend resources on non-critical things. I know it will get critical someday, so we are slowly finding a solution to it.
      - redwood 11y ago
        Schema design allows you to grab stuff you want joined all at the same time (aka the data lives together in a document) in mongodb's model. This obviously has limitations in many to many relationships where the access pattern isn't clear, but often these tradeoffs can work.
    - 11y ago

jshen 11y ago

"This announcement just underscores the importance of having full control over your backend" I disagree. If using something like this let's you get to market much faster, much cheaper, and find market fit faster/cheaper, then it's worth it. Depending on the need it can take millions of dollars and year(s) of work to then begin working on the actual business objectives.

nodamage 11y ago
If you're building a nascent mobile app it probably won't take millions of dollars and year(s) of works to get up and running, regardless of what backend you use. If you do have a project that will take millions of dollars and year(s) of work to get up and running, I'm going to guess you have much bigger problems than what backend you use, and choosing something like Parse won't help you that much.
jonsterling 11y ago
We used Parse, and (contrary to your suggestion) it helped us get to market much slower and much more expensively. We experienced a hilarious amount of downtime, and hundreds of engineering hours that could have been spent developing features for our users or improving our services were spent working around fatal bugs in Parse, which were usually not manifesting on all instances, which made it very difficult for the Parse team to diagnose them. Fixes for Parse bugs were usually not forthcoming from the Parse team---and when things were fixed, more often than not the fix was reverted within a week because it caused something even worse. For the first six months of our time using them, Parse would only report downtime post facto and backdated by a day. “F@#$k Parse” was perhaps the most frequently uttered phrase among all of us in our douchebag Mission district headquarters. What a life. All the time, push notifications inexplicably stopped working for hours at a time---we were running a daily sales app, and this really killed us. It ruined dozens of auctions and pissed off tons of our users. But what's even worse? Parse made my life a living hell for a year, and I'm glad they're gone.
- AlwaysBCoding 11y ago
  It's a good thing they had great documentation... oh wait.

st3v3r 11y ago

No, it just underscores the importance of properly architecting your apps so that they don't directly depend on Parse or others. Keeping that stuff to the periphery of your app will make it much easier to replace when the service either shuts down or you outgrow it.

nodamage 11y ago
Eh, regardless of how well your application is architected, it's going to be a pain in the ass to migrate if you have a lot of data/users/versions of your app out in the wild. If you continue to rely on BaaS providers you run the risk of playing perpetual musical chairs as each one shuts down over time. That's not an acceptable level of risk for me, but, to each his own I guess.

rackforms 11y ago

100% agree. Building my first notification-based app right now and Parse seemed like the obvious and best choice. Thing is, after a bit of thinking something felt...off. Not with the service, but off with the idea of attaching this small little project to something so...out of my control. I dug around the net and found a working solution I could install on my own server, and now that's exactly what I've got: The experience of doing this on my own, the flexibility to grow as needed, and the code to implement again and again without needing anyone or anything else. Building apps these days is a massive gamble for small guys like me. We often spend dozens of hours with little to no possibility of return. Any action I can take that reduces stress points and increase my knowledge base, (and this would have been a massive stress point) I'll take.

geoka9 11y ago
May I ask what that solution was? :)
- rackforms 11y ago
  Absolutely! Please do keep in mind no system is perfect, 100% reliability is a dream we all strive to attain, and even with Parse, I've read several reports on this very thread of instances of less than perfect reliability, iffy technical support, and so on. Anecdotal sure, but still. That said: the app sends basic notifications when in-app, user-initiated events of interest occur. The server code is PHP, based off of this fantastic little tutorial: http://www.raywenderlich.com/32963/apple-push-notification-services-in-ios-6-tutorial-part-2 http://www.raywenderlich.com/32963/apple-push-notification-s... I modified and use the code in the simplest possible way: I created the API layer using my wonderful form builder software (https://www.rackforms.com https://www.rackforms.com). Yup, it's form software flexible enough to write endpoints. Check it out : ) The app sends simple GET requests to my server, which are in turn handled by the API job. If a notification is required, the API INSERT's a record into a MySQL table called push_queue. The magic, I suppose, happens with a constantly running PHP script called push.php. This guy's monitored by a simple cron job that checks for its running status every minute. if it's down, cron automatically restarts the script. The notifications are not time-sensitive that 1 minute delays are a deal breaker, and of course any sent during that time are handled automatically when the script restarts. APN Feedback is handled by a second one-the-hour cron job, which calls a simple script called feedback.php. A touch of code was added to deal with the core user's device token being removed for "followers" of that user. Three Key Takeaways: 1. The entire server setup part took me about 5 hours, API code (which we'd need to write regardless) not withstanding. The biggest hurdle was the cron stuff, I shall never forget cron -v cron! Using a third-party service would have been almost the same time, I'd imagine. The best part is future projects will literally be counted in the minutes for start to finish notification server duties. 2. I got to use a language I adore (PHP), and learned a bunch with others I was quite new too (shell scripting, cron, etc). 3. Finally: No app is guaranteed success. I know many of these services have/had! generous free tiers, but after my first app (http://www.skipcast.net http://www.skipcast.net) and its frankly lousy performance, fool me once indeed. If, by some miracle, this new app gains traction, sure, I'll consider a third party. Until then, I'll do it my self thank you very much. In all -- a wonderful experience that I'm keen to tweak and learn more from at deployment time.

snej 11y ago

[Couchbase Lite architect here, so I have skin in this game] Even better, if you're using an open protocol, you can work with _either_ a hosted back-end or one you own, and move between them pretty easily. HTTP being a good example of course. The problem is that open protocols for general purpose data sync are pretty thin on the ground. Couchbase built our sync architecture on top of CouchDB's replication protocol, which was badly documented at the time but at least open. Couchbase Mobile (http://couchbase.com/mobile http://couchbase.com/mobile) uses this open protocol, so you can either BYO server (our own Couchbase Sync Gateway, or CouchDB) or use a hosted one like Cloudant. And you've got full access to the code (ours is all Apache licensed.) I can't say we're directly compatible with Parse, or trivial to migrate to (the data models and APIs are different), and I'm obviously biased, but I do think it's a good alternative to jump ship to.

pashakym 11y ago
you better build something quick :) to help all of us (independent developers)

nodamage 11y ago

A few more thoughts: 1. This effectively poisons the well for any other BaaS providers out there. If two of the biggest companies in this space (StackMob and Parse) can get acquired and shut down in less than 5 years, what does that say about the future of the smaller companies in this space? As a developer how could you possibly trust any of these companies going forward, based on this track record? 2. Syncing is notoriously difficult to get right. Building a generalized syncing solution is even harder. Bugs in sync code tend to lead to data loss, which leads to angry customers. These types of bugs are hard enough to track down and fix in your own code. Trying to track down and fix bugs in complex third-party code can be damn near impossible. If you decide to adopt a third party solution that purports to do your syncing for you, do your research carefully. Not just by looking at the toy samples which look easy to set up and work perfectly, but experiences and reports from actual developers who have tried such solutions. What kind of problems are they having? What are the limitations of the current implementation? How mature is the product? How responsive are they to bug reports? If something goes wrong and data is lost, how much insight do you have into the system to figure out why?

bikamonki 11y ago
Au contraire: it opens a wider deeper well. Parse customers are now up for grabs. Do you think they will go back to program back-ends and rent a server? I personally won't. So the supermaket chain where you usually shop at closes its stores for whatever reason. Do you go back to farming your backyard or do you find a new store? The BAAS industry is super young, only hipsters are into it. But it makes sense so it will eventually mature. Bugs will be fixed.
- nodamage 11y ago
  Switching supermarkets is much, much, easier than switching backends. I'm sure lot more BaaS companies will pop up to grab former Parse customers. I'm not sure how many of those will still be around in another 5 years. I strongly suspect there's something negative about the economics of BaaS services that's being implied by the fact that two of the most successful providers have shut down after acquisition.

bikamonki 11y ago

Wrong! Everything we build is on top of layers upon layers and not a single company/IT team has/can fully control all of them! So you suggest: build your own backend API and run it on a VPS/Container/whatever. Do you have full control on the hardware? The virtual machines? The vendor's infrastructure? Let's move a layer up. Do you have full control over the framework you used? The database engine? Does the sum of knowledge/experience in your team guarantees full control on all these layers? Under a security threat who provides the patches? Your team? Do you run your own mail server? Did you code our own OS? This is rethorical of course, all the answers are no. What exactly is wrong about trusting one more layer to 'experts'? Not all dev teams can afford a backend ninja just as they cannot afford a network admin or a telecom engineer. Companies like Parse are on the right track, they provide a much needed service. I've been on this trade long enough to witness the transition of companies hosting webservers in-house to realizing a dedicated server made more sense (one team of experts managing many machines), then VPS, then containers....then BAAS.

nodamage 11y ago
Your reductio ad absurdum is not particularly convincing. I draw the line at exactly the BaaS layer specifically because of the high risk of these providers pulling the rug out from under you. If you disagree, fair enough, but I feel pretty bad right now for the poor developer who decided to adopt StackMob, then migrated over to Parse when StackMob shut down, and now has to migrate once again. Fool me once...
- bikamonki 11y ago
  You'll move that line eventually. Datacenters were a hard problem to solve a decade ago. Now its (almost) trivial. Virtual clouds were a buzzword less than two years ago. Now they are huge and successful businesses. Same path for BAAS.
  - nodamage 11y ago
    That's possible. But the current model of "give us money, use our code, and we'll host your data" is pretty clearly broken.

petke 11y ago

Not to be a dick, but some companies seem to care more than others about the developers that rely on their frameworks. Google doesnt seem to care much. Facebook seems to care more. But Microsoft seems to care most. They have not abandoned legacy mfc, visual basic, and win 32 developers even though they probably should have. Granted those are not services but they require maintenance resources nontheless.

stickfigure 11y ago
Eh? I have apps that are almost 10yo on Google App Engine. Even when they forced a complete migration from the Master/Slave datastore to the High Replication Datastore, it was a pushbutton process that required minimal intervention. Honestly if I have any complaint it's that they don't force change faster. On the other hand, Facebook's API changes at a pretty rapid pace and there are few apps older than a couple years that have survived without significant code changes. I've seen API changes that are basically "rewrite your whole app".

s_dev 11y ago

How is this any different to depending on Amazon for your back end?

argo12 11y ago

Developers will now be skeptical about using any BaaS. It can be acquired and shut down. They have every reason to be. We built a BaaS too. It is however built around this core philosophy of developers having complete control over their app backends. Here is the post we wrote about this: https://news.ycombinator.com/item?id=10994104 https://news.ycombinator.com/item?id=10994104

akarve 11y ago

for most applications i hypothesize that the cost of writing and maintaining your own backend will far outstrip the cost of the occasional migration. if anything, the pressure is towards frontend:backend isolation, not away from BaaS. (in the spirit of segment.io for analytics.) one ironic signal here is that money is bad for survivorship. facebook killed parse because it doesn't move the needle for facebook, but parse might have been a fine & profitable standalone business.

Salgat 11y ago

All this underscores is the important of not tightly coupling your codebase to a particular provider.

nodamage 11y ago
It doesn't matter how tightly coupled your codebase is. If you have a client app that talks directly to Parse.com, it will stop working a year from now, and you will have orphaned users. Even if you release a new build that points to a new backend, not everyone regularly upgrades, not everyone can upgrade.