Parse is different from Heroku is a very big way - vendor lock-in. You are using the Parse libraries, DB, push notifications, etc, and replacing that will be quite difficult. Heroku, on the other hand, is usually just a generic Rails stack (or java or clojure), which is easily moved.
The client API requires that you provide it your app's global credentials. These are likely to be baked right into the code, so can be easily extracted from the binary. It looks like the entire datastore is mutable/queryable after authentication by default. Privileges can be revoked on datastores after creation, which is obviously not ideal since it limits your app's capabilities.
In its current form, this is inappropriate for all but the most basic use cases.
Hi Scott. Just to clarify, the client API does not use the app's global credentials, but the client credentials which have their access limited in several ways. One is the per-column access configuration, which lets you set up objects where access is restricted to users with the relevant token. The other main security restriction is user-based authentication, which ensures user data can only be updated by a client authenticated as that user. The combination of these security methods handle a lot of use cases, and we're always looking to add more security functionality to make more use cases work securely.
If you have a specific application in mind, I'd love to chat with you about how it maps onto our security model. Feel free to drop me a line at kevin@parse.com.
I do see "class" level permissions, as I mentioned in my previous post, but nothing suggesting that finer grain control exists. I do see that you can store data on the authenticated user, which is a good start.
And if better security is something that's in the works, that's great. I'm not looking to give you guys a bad name. I just saw this being talked about in the startups I work around, and felt as if some of the less experienced developers were not considering what implications using a service like this might have. It's convenient, I'll give you that -- but instead of facilitating good security through its APIs, it obscures the need for it altogether. And from what I can see, it would be difficult for you guys to encourage good practice without being heavy handed.
Let's just hope your users are smart about how they use your product, because I'd hate to see what effect a few breaches might have.
That's a good way to describe our goals with Parse security - to "encourage good practice without being heavy handed". We are always looking for ways to make Parse easier, including security, so we definitely won't stop with what we have now. If you have specific suggestions feel free to drop me an email.
Why am I being downvoted? As responsible engineers, we should be deeply suspicious of anything coming from the client. This product flies in the face of that wisdom.
Parse sounds like it will be another Urban Airship, not Heroku, unless:
- They enormously extend their offering to support development of arbitrary server-side code.
- They figure out how to do this in a way that doesn't introduce inescapable lock-in for application developers.
- They figure out how to differentiate this offering from what similar server-side deployment/platform services already provide (Heroku, EC2, AppEngine, whatever).
That's not to say UA or Parse won't ever see a big exit (in this market, who knows). Rather, I seriously doubt -- in either case -- that the economics are there for more than a profitable "lifestyle business".
(no negativity implied -- I favor lifestyle businesses, but VCs don't).
In regards to your first bullet, one of Parse's competitors, CloudMine, allows developers to write their own server-side JavaScript code that executes within a sandboxed environment: https://cloudmine.me/developer_zone#code/overview
Got your point, but I think Parse.com's goal is to provide a data persistence service for Mobile developers that DON'T want to code anything on the server side. It's a simple persistence service, why would I code anything on Javascript in a third party/hosting or SDK like Cloudmine if I can do the same thing in Heroku or Joyent using the full power of Node.JS? :)
I build a Cloudmine app yesterday at a Hackathon. Setup was very fast and early one we didn't have a need for server-side processing. But then requirements evolved (as they always do) and we found the Javascript hooks very useful.
Speaking as someone who has never used node.js before, it was nice to not have to worry about setup and just start coding.
Urban Airship has something like 55 employees, just acquired SimpleGeo for several million, and just closed a $15m Series C from top VCs. May we all be cursed with such a "lifestyle business."
I'm talking about simple profitability, not whether they've been able (or needed) to raise 20+ M in less than 2 years. I've yet to see it demonstrated that they actually have a business model to sustain their 50+ employees (especially given UA's lack of focus and their returning repeatedly to the VC trough).
Engineer from StackMob here (http://stackmob.com). We agree that the need to extend your API on the server side is a huge part of what we are working to achieve in this space. That is why we have always had our "custom code" offerring, allowing you to extend your API in Scala, Java or Clojure. Our partnership with Heroku has also opened up Rails applications to be extensions to your API as well.
As for lock-in we have always said from the beginning that our customers own their data and can take it with them at any time. I think you may find a recent blog post by our co-founder of interest as well: http://www.stackmob.com/2011/11/why-a-paas-for-mobile-develo...
Ownership of data is just one tiny sliver of vendor lock-in with PaaS. The wider issue is how much "stuff" needs to be reimplemented to move to another platform.
Sometimes that's not so bad - if what you have to reimplement is stuff you'd inevitably have to build yourself if you didn't have the PaaS provider, then you're just deferring the cost of it (potentially "forever"). But often you would make different choices if you did not have the choice of the PaaS.
That is why ideas are many but execution is key to a success of a startup. There are many ways I can see Parse getting to a size that of Heroku.
You may not see the potential and that's because you have no idea of what's coming up and I'm sure the founders at Parse have that piece of information and it's going to be at least a $200M exit if they execute to their vision.
[Edit] Wow. OK, would a downvoter do me the favor of explaining why they find my position so repugnant, rather than just hitting the down arrow (as convenient as that may be?). Maybe I'll learn something.
You may not see the potential and that's because you have no idea of what's coming up and I'm sure the founders at Parse have that piece of information ...
Anyone with sufficient experience in developing large-scale mobile applications should have a pretty good idea of where this can go, and what to expect out of the potential customer base.
We're talking about a very familiar space of developer tooling, not rocket science.
... and it's going to be at least a $200M exit if they execute to their vision.
[Edit] In retrospect, venturing a guess here is too silly to do. $200M seems insanely high, regardless.
If I could commit a couple of years of my life to work at a company right now (and hey, I may still be able to depending on various circumstances) Parse would certainly be up there.
Seems like an awesome product, and user feedback from pretty much everyone involved has been overwhelmingly positive. That's a good combination.
Great round well deserved.
(Full disclosure, this isn't a space I've worked in before, I'm just going on what people I respect who are in the space have said)
If I could commit a couple of years of my life to work at a company right now (and hey, I may still be able to depending on various circumstances) Parse would certainly be up there.
Well if you change your mind, we are certainly hiring. Just send a resume to jobs@parse.com ;-)
I've been using Parse to build one my apps votespot. As the others said, it's one of the easiest framework to integrate with your project. The team are very helpful and listen to users problems, they even answer emails on weekends. Again kudos to the team. Sorry if I've been bugging you guys with questions and non-sense issues =)
This morning Adobe announced that they were shutting down Flash for mobile (vendor lock-in): Everyone praising.
This afternoon, we have Parse that raises 5.5M$ (More vendor lock-in): Most people praising.
To me, Parse sounds like an utopia. It does look very promising and the premise is very interesting. However, what happens if you need to move to some other backend (If you hit an Instagr.am's hockey puck growth for example)?
If you want analytics on your backend?
How about if you need to moderate some of your content?
Lots of black magic and while you can just switch a DNS entry on heroku, you can't do so on Parse...
A couple notes. Analytics and content moderation are possible right now through the REST API - we have developers using the API for both of those in fact.
You can also moderate content manually through the data browser.
As far as scalability goes, our team has a lot of experience designing web-scale products. We're designing Parse from the ground up to scale. If anyone has an application that they're concerned how Parse can handle the load, we're glad to chat about it - just drop us a line at feedback@parse.com.
Parse probably has the easiest-to-integrate library I have ever used...in my life. It took me five minutes to have a database backend to store 'share event's for my mobile apps.
How similar is Parse to Urban Airship? I notice Parse lists push notifications on their homepage, and that seems to be one of the big things about Urban Airship.
Parse offers a lot besides push notifications as well - you can store arbitrary data on Parse, do user authentication, and access the data from non-mobile devices using the REST API. We'd be glad to answer any other questions you have at feedback@parse.com.
It depends on your definition. Define Heroku as web servers in the cloud. Then sure nothing alike. Define Heroku more generally as Web back end in the cloud. Then define parse as mobile back end in the cloud. They now share "back end in the cloud" and differ on what back end they provide with some overlap.
Thanks! We thrive on user feedback so feel free to send us suggestions for new features or ideas about what could be made easier in mobile development. feedback@parse.com
Parse user here, I think it's great. I'm curious to see if they do anything with their Facebook integration. I could see them building a user interest profile based on what apps the user has which could be very valuable to both developers and advertisers.
While I love the idea I wonder how dangerous it is set your business on top of this thing given the possibility Parse can go out of business some time in the future? I mean, it ain't no AWS backed by Amazon that has quite the track record.
Remember that the alternative is no business at all.
We have a similar product where we provide a backend for game developers, and there are quite a few of them making quite a lot of money on it. But without us, those single developers or small teams simply wouldn't be able to pull off the games that they do, because they don't have the knowledge or resources to make the backend systems we offer.
If you can afford to make your own backend systems, you're not the target for Parse, or us.
(Oh, and it's not like AWS has a 100% stellar track record either. :-) )
