3 ms·

I guess I'm old fashioned, but I never really "got" Parse and other hosted backend services. It's easy enough to build a backend that talks to a mongo-like data

I guess I'm old fashioned, but I never really "got" Parse and other hosted backend services. It's easy enough to build a backend that talks to a mongo-like database (for the vast majority of use cases), especially with help from the hundreds of awesome and free libraries/drivers out there. Plus, you don't have the risk of some business executive randomly deciding to kill your backend, and when you're debugging, it's one less chance of the bug being in the platform you're relying on and not your code (which is something you can immediately do something about).

jacalata 11y ago
Not old fashioned so much as unable to understand the variety of backgrounds, skills and priorities that app developers have.
- jliptzin 11y ago
  Well, if an app developer can't figure out how to store and retrieve user data in a simple nosql database, or set up a simple cloud server, or believes a backend is not worth spending any time on, I wouldn't have high hopes for that app.
seanwilson 11y ago
> and when you're debugging, it's one less chance of the bug being in the platform you're relying on and not your code (which is something you can immediately do something about). That's generally why you want to use them. You're using something that is already battle hardened and tested.
aikah 11y ago
Push notifications, ACL management done in a nice way, ... nothing that cannot be built quickly but you know how it works, one start with a prototype on Parse, because it's RAD, and the product ends up being the prototype because ... RAD . Granted there were other open source Baas before, but Parse had an nice UI admin, along with nice analytics. Overall it was a good product feature wise.
st3v3r 11y ago
Build it? Maybe. Secure it? Run it? Scale it? Not so much. "Plus, you don't have the risk of some business executive randomly deciding to kill your backend" This isn't really that common, so it's not really something to worry about.
arstin 11y ago
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.

jacalata 11y ago

Not old fashioned so much as unable to understand the variety of backgrounds, skills and priorities that app developers have.

jliptzin 11y ago
Well, if an app developer can't figure out how to store and retrieve user data in a simple nosql database, or set up a simple cloud server, or believes a backend is not worth spending any time on, I wouldn't have high hopes for that app.

seanwilson 11y ago

> and when you're debugging, it's one less chance of the bug being in the platform you're relying on and not your code (which is something you can immediately do something about). That's generally why you want to use them. You're using something that is already battle hardened and tested.

aikah 11y ago

Push notifications, ACL management done in a nice way, ... nothing that cannot be built quickly but you know how it works, one start with a prototype on Parse, because it's RAD, and the product ends up being the prototype because ... RAD . Granted there were other open source Baas before, but Parse had an nice UI admin, along with nice analytics. Overall it was a good product feature wise.

st3v3r 11y ago

Build it? Maybe. Secure it? Run it? Scale it? Not so much. "Plus, you don't have the risk of some business executive randomly deciding to kill your backend" This isn't really that common, so it's not really something to worry about.

arstin 11y ago

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.