Introducing the Parse Windows 8 SDK(blog.parse.com)
blog.parse.com
Introducing the Parse Windows 8 SDK
http://blog.parse.com/2012/10/25/introducing-the-parse-windows-8-sdk/
15 comments
1) You aren't looking hard enough, go look through their app gallery. For my part, I've deployed Parse in Gaia GPS, StopWatch+, Shark Net, and it's saved me mountains of time. Gaia GPS is the highest grossing hiking app on the App Store, and Shark Net was downloaded a bazillion times as part of Shark Week.
2) Why would developers stick with Parse? Well, because the price is just negligible for what you get - there will never be a good ROI to switch away. You can use Parse at the Pro level for literally years, and it doesn't cost as much as a week of effort from an A-level developer.
Parse = $4800 for two years
Awesome Developer = easily $6000 for a week of work
3) I love Parse for how easy it is to whip up server-side stuff, where I'd like some flexibility in how it's implemented. Before, I would write features and have to ship new versions if I wanted to make a change. Now when it occurs to me to make something server-configurable, I don't heistate to use Parse - it just doesn't add any time over using strictly client-side stuff. And the web interface makes it simple to "admin" and tweak the features.
Don't even get me started on how easy Parse makes it to do Push notifications and how well that works.
2) Why would developers stick with Parse? Well, because the price is just negligible for what you get - there will never be a good ROI to switch away. You can use Parse at the Pro level for literally years, and it doesn't cost as much as a week of effort from an A-level developer.
Parse = $4800 for two years
Awesome Developer = easily $6000 for a week of work
3) I love Parse for how easy it is to whip up server-side stuff, where I'd like some flexibility in how it's implemented. Before, I would write features and have to ship new versions if I wanted to make a change. Now when it occurs to me to make something server-configurable, I don't heistate to use Parse - it just doesn't add any time over using strictly client-side stuff. And the web interface makes it simple to "admin" and tweak the features.
Don't even get me started on how easy Parse makes it to do Push notifications and how well that works.
We have some very serious brands on board including Home Depot, Armani, Food Network, Green Bay Packers, Discovery Channel, Cadillac, and more. The folks building these apps don't want to be working on caching policies. They want to make beautiful, engaging applications. They stick with us because it's just easier.
I can completely understand the decision to use Parse. On the flip side of what the parent commented, big players who only have a comparatively limited presence in the mobile world don't always want to have to hire a full team just to implement their one or two simple apps. Conversely, a small player might not have the resources to hire a full team, or might not have the know-how or time to implement it themselves.
A team that is deeply invested in mobile might want to engineer their own solution. If you're a mobile-only company or even a mobile-first company, I would expect you to have a full backend team. Otherwise, contracting out the bit you don't have resources for just makes sense. That's where I see Parse sitting in the world, and with the client list you mentioned, it seems to fit perfectly. I wouldn't expect Home Depot to have a complete mobile team.
A team that is deeply invested in mobile might want to engineer their own solution. If you're a mobile-only company or even a mobile-first company, I would expect you to have a full backend team. Otherwise, contracting out the bit you don't have resources for just makes sense. That's where I see Parse sitting in the world, and with the client list you mentioned, it seems to fit perfectly. I wouldn't expect Home Depot to have a complete mobile team.
I'm not so sure about this.
I'm writing a pretty complicated application using parse. It's been great so far. I've been a very vocal non-fan of their iOS SDK though, so much so that I'm actually dropping it in favor of a custom written job using their REST API instead. But besides that one thing, it's been fantastic.
The new Cloud code stuff they just added is awesome.
I spent 10 years doing heavy backend shit until about 5 years ago when I switched back to native front-end development. I still am having to write a service here or there to cover some holes that Parse doesn't cover for this application, but those are pretty small holes.
A+++ would use again.
I'm writing a pretty complicated application using parse. It's been great so far. I've been a very vocal non-fan of their iOS SDK though, so much so that I'm actually dropping it in favor of a custom written job using their REST API instead. But besides that one thing, it's been fantastic.
The new Cloud code stuff they just added is awesome.
I spent 10 years doing heavy backend shit until about 5 years ago when I switched back to native front-end development. I still am having to write a service here or there to cover some holes that Parse doesn't cover for this application, but those are pretty small holes.
A+++ would use again.
As a (paying) customer of Parse, and someone who really like their iOS SDK - what is it that you don't like? Is it that the stuff you're trying to do doesn't play well with the way the SDK is architected, or is a more general dislike of the approach (compared with, say, the rather more structured incremental-store based SDK that StackMob use)?
I don't like that subclassing generally doesn't work. You can subclass PFObject no problem, but you lose it when you are doing a lot of PFQuery'ing. PFUser would be a prime candidate for subclassing but that really doesn't work without a lot of shim'ing.
I don't like the lack of client side persistence. There is caching with PFQuery but it's caching the json response from the server. For example, let's say I have a message board with 1000 messages. If the user posts a message, I can't simply add the new post and have it cached, I would have to query and pull down all 1001 messages.
Now, I've written all the boilerplate around the parse SDK to do all of this, but it was kind of hacky. So now I'm ripping it all out and just using the REST API with my own custom digs. Much smoother. I'm slowly moving it over to it's own static lib at: https://github.com/jawngee/CloudObject
Don't get me wrong though, their SDK is definitely usable, but after a certain point it becomes a little cumbersome.
I don't like the lack of client side persistence. There is caching with PFQuery but it's caching the json response from the server. For example, let's say I have a message board with 1000 messages. If the user posts a message, I can't simply add the new post and have it cached, I would have to query and pull down all 1001 messages.
Now, I've written all the boilerplate around the parse SDK to do all of this, but it was kind of hacky. So now I'm ripping it all out and just using the REST API with my own custom digs. Much smoother. I'm slowly moving it over to it's own static lib at: https://github.com/jawngee/CloudObject
Don't get me wrong though, their SDK is definitely usable, but after a certain point it becomes a little cumbersome.
PFObject subclassing and a more comprehensive offline solution are both very high on our list of features we would like to add. We're just taking our time to make sure we get them right. :)
Parse should offer a dedicated enterprise solution to run their stack (as source code) and warehouse your data on your own servers (or own AWS account). That would offer a real migration path for apps that anticipate reach critical mass in their user base.
Saw a good roundup of the MBaaS providers, here:
http://apievangelist.com/2012/08/22/mobile-backend-as-a-serv...
We use Parse for some apps and roll our own Rails backend too. Of all the MPaaS providers we've investigate, Parse seems to be getting things right: SDK's are solid & the documentation is up-to-date, 3rd party integration with Twitter / FB / S3 work great. It's a joy to get started.
The biggest problem we've seen so far are on caching, user models, analysis and emails:
- Local native caching on devices seems capricious, and we've often reverted to writing our own caching schemes on top of Parse (had to do the same for server-side, too, but maybe that's a given...)
- User data model is pretty basic, and although the ACL capabilities are nice, it's not easy to build (FB invite requests work, but outside of that framework you have to roll your own invite / accept / reject / exit logic)
- Custom emails on User model CRUD / password are supported, but not for any other user interaction (ie., weekly roundup emails, status updates, etc.)
- API introspection is tough, it's not easy to optimize (ok, minimize) API calls and some form of introspection & analysis would be helpful (eg., just when do the SDK libraries synchronize, and how often?)
All that being said, I don't think any of their competitors have done a better job on these topics and certainly Parse seems to be pulling away from the MPaaS pack.
We use Parse for some apps and roll our own Rails backend too. Of all the MPaaS providers we've investigate, Parse seems to be getting things right: SDK's are solid & the documentation is up-to-date, 3rd party integration with Twitter / FB / S3 work great. It's a joy to get started.
The biggest problem we've seen so far are on caching, user models, analysis and emails:
- Local native caching on devices seems capricious, and we've often reverted to writing our own caching schemes on top of Parse (had to do the same for server-side, too, but maybe that's a given...)
- User data model is pretty basic, and although the ACL capabilities are nice, it's not easy to build (FB invite requests work, but outside of that framework you have to roll your own invite / accept / reject / exit logic)
- Custom emails on User model CRUD / password are supported, but not for any other user interaction (ie., weekly roundup emails, status updates, etc.)
- API introspection is tough, it's not easy to optimize (ok, minimize) API calls and some form of introspection & analysis would be helpful (eg., just when do the SDK libraries synchronize, and how often?)
All that being said, I don't think any of their competitors have done a better job on these topics and certainly Parse seems to be pulling away from the MPaaS pack.
Thanks for the feedback. We're working on improving each one of those areas.
That's an awesome move guys. Congratulations, you're moving real fast.
I've never used Parse before, haven't really needed it, but I just bought a Surface and have my developer license ready to go. Time to have a stab at it tomorrow night.
The Buddy Platform provides a similar service to Parse, but is more scenario focused. They too are on fire (I'm an investor and advisor).
Buddy has had a Win SDK available for months [1].
[1] http://www.buddy.com/documentation.aspx#SDKs_and_Samples
Buddy has had a Win SDK available for months [1].
[1] http://www.buddy.com/documentation.aspx#SDKs_and_Samples
A Windows 8 SDK with .NET and JS... but no C++? :(
EDIT: Please don't get me wrong. My proposition was in terms of how many serious apps will adopt Parse. I currently use parse for 3 of my apps and love it. But I am a free user and never bother paying for their service coz there is no need for it.