I only tried Parse for one prototype two years back, but I take it I'm the target audience.
Your point is probably valid if you identify as a backend web dev, but different people have different priorities. I'm personally a product designer first and a developer second. Sure, I can set up and deploy a simple backend, but I don't enjoy it and I have no interest in learning the complexities of scaling it. Any time that I have to spend dealing with data persistence or managing a server is time spent outside of where my attention naturally rests.
Compare to a developer spending days tweaking the shadows and padding and colors and fonts of a UI component. It's "easy" to do, and it's important enough that (given the choice) many people wouldn't use an app which paid no attention to that level of detail, but it's likely time spent away from what they really want to be working on and to which they can best contribute. So just drop in Bootstrap and maybe later get a visual designer to help swap it out.
That's how I feel about backend services. Use a backend service until the app outgrows it, then---if that point is reached---it might be established enough to have someone focused on that problem swap the BaaS out for a custom backend. You have to be careful to keep your code sensibly decoupled and organized...but that's a good practice anyway (and is also the defense against your very relevant worry about the service shutting down). In fact, the app I'm working on now is at a point where, after a year, we are replacing the firebase backend with our own solution.
Basically, BaaS's can be a good crutch for some people---especially small, product design focused teams---because they remove complexity. Just like Bootstrap or Material UI can be a good crutch for small, data management focused teams. It removes complexity. Even if the complexity in each case doesn't seem to be high, every little thing to worry about adds up, and it's good to have the option of making tradeoffs.
Comments
I only tried Parse for one prototype two years back, but I take it I'm the target audience.
Your point is probably valid if you identify as a backend web dev, but different people have different priorities. I'm personally a product designer first and a developer second. Sure, I can set up and deploy a simple backend, but I don't enjoy it and I have no interest in learning the complexities of scaling it. Any time that I have to spend dealing with data persistence or managing a server is time spent outside of where my attention naturally rests.
Compare to a developer spending days tweaking the shadows and padding and colors and fonts of a UI component. It's "easy" to do, and it's important enough that (given the choice) many people wouldn't use an app which paid no attention to that level of detail, but it's likely time spent away from what they really want to be working on and to which they can best contribute. So just drop in Bootstrap and maybe later get a visual designer to help swap it out.
That's how I feel about backend services. Use a backend service until the app outgrows it, then---if that point is reached---it might be established enough to have someone focused on that problem swap the BaaS out for a custom backend. You have to be careful to keep your code sensibly decoupled and organized...but that's a good practice anyway (and is also the defense against your very relevant worry about the service shutting down). In fact, the app I'm working on now is at a point where, after a year, we are replacing the firebase backend with our own solution.
Basically, BaaS's can be a good crutch for some people---especially small, product design focused teams---because they remove complexity. Just like Bootstrap or Material UI can be a good crutch for small, data management focused teams. It removes complexity. Even if the complexity in each case doesn't seem to be high, every little thing to worry about adds up, and it's good to have the option of making tradeoffs.