Most of developers will worry about any other BaaS will shit down as Parse does. A new alternative might be in a way of "take-away-parse" hosting solution. Not necessarily open-source but would be nice if it is.
> Not necessarily open-source but would be nice if it is.
I don't see any product like this succeeding if it doesn't allow customers to install the app on their own servers, frankly it's the end of wall gardened BaaS solutions, period. Firebase and co aren't going to fool anyone on that matter, they need to release an opensource version.
May from parse-hosting.oursky.com here, sorry as we are hosting the landing page on Heroku (yea I know it is ironic but it get the job done quickly), so when there was a spike of traffic it shows the 500 error.
For parse-hosting, we will host each paid client on a dedicated AWS account, which is a different thing :)
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).
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.
> 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.
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.
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.
Yap but most of these migrations only migrate the data but left our Parse CloudCode, Web Hook, Background Jobs, etc.
Not to mention the on-going maintenance of Parse Server such as upgrade / security patch.
So a parse hosting service is to keep expanding offers on top of Parse Server open source implementation, and help provide the same hassle-free services some app developers looking for.
I am not using parse's backend services. I am using its push services. Has anyone had experience with Amazon Simple Notification Service? I am thinking switch to aws sns (https://aws.amazon.com/sns/).
Some quick feedback. You guys need to offer a "Hobbyist" plan for around $30-60/per month. Otherwise you are really only shooting for a very small portion of Parse users with your base price starting at $199/per month. Then again that just leaves the market open for someone else to offer more affordable prices. Good luck.
Thanks! Actually, we're working on it. The key is for that price range we need to do it on shared hosting (instead of dedicated servers); We will put up a waiting list for people who are interested in "Hobbyist plan" soon.
Previous code-base should rely on your own parse-server hosting IMHO. The dream of not worrying about servers AT ALL isn't exactly tangible, I think.
I've written a short introduction to a BaaS I've been working on in the last couple of years, it would be great if we as a community embrace new ideas and have another good tool to do a great job as Parse had been doing: https://medium.com/@endel/hook-open-source-alternative-to-pa...
> The dream of not worrying about servers AT ALL isn't exactly tangible, I think.
Devops here. My bread and butter is people who start with "not worrying about servers" who eventually have to transition to "year, I'm gonna have to worry about servers".
It's probably worth pointing out that if you have existing released apps that depend on Parse and you want to preserve data continuity, it's pretty much necessary to transition to Parse Server.
24 comments
[ 4.5 ms ] story [ 59.4 ms ] threadI don't see any product like this succeeding if it doesn't allow customers to install the app on their own servers, frankly it's the end of wall gardened BaaS solutions, period. Firebase and co aren't going to fool anyone on that matter, they need to release an opensource version.
For parse-hosting, we will host each paid client on a dedicated AWS account, which is a different thing :)
That's generally why you want to use them. You're using something that is already battle hardened and tested.
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.
"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.
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.
(disclaimer: I work for Microsoft)
Not to mention the on-going maintenance of Parse Server such as upgrade / security patch.
So a parse hosting service is to keep expanding offers on top of Parse Server open source implementation, and help provide the same hassle-free services some app developers looking for.
It's micro services. Remember 2000 data centers? Everyone was afraid to go Cloud.
I predict cloud is going to die, like it or not, up next is microservices by many names. http://www.programmableweb.com/apis/directory
That is the future.
I've written a short introduction to a BaaS I've been working on in the last couple of years, it would be great if we as a community embrace new ideas and have another good tool to do a great job as Parse had been doing: https://medium.com/@endel/hook-open-source-alternative-to-pa...
Devops here. My bread and butter is people who start with "not worrying about servers" who eventually have to transition to "year, I'm gonna have to worry about servers".
Best thing you can do is be self-sufficient and self-reliant.