July 14th, 2013, 12:55 PM
Using Parse as a mobile backend ?
Curious if anyone has any experience using Parse (https://www.parse.com) as a mobile backend/cloud/DB to provide a platform for DB tables and APIs? I am looking at that, along with Riak, for use in some client-based mobile app projects that are coming up. In the past, we have had to build our API's from scratch using a server and PHP or .NET, etc, but the discovery of these new platforms has me a bit intrigued (and very excited at the possibility of eliminating a lot of overhead involved in doing this kind of thing from scratch).
Any advice would be greatly appreciated from anyone with experience with this tool. Thanks!
July 23rd, 2013, 08:55 AM
I used parse once. But defining the key-value pairs was really grinding my gears. Plus parse belongs to facebook now and I'm not sure where this is leading. So I started to look for alternatives and found these guys: apiOmat
Originally Posted by BlastPort
They offer generated SDKs which means you can create your object, give it some attributes and save it. And whoooosh its on the server ;-) Another benefit is that their cloud is hosted in germany (best privacy law etc etc) I don't say parse is bad, but I think there are better provider out there.
July 23rd, 2013, 11:18 AM
Good find on apiOmat, as that is not one that I have heard of before. Only drawback to it seems to be that the free plan is a bit limited. But you are correct that Facebook's ownership of Parse is actually a concern in the development community (especially with their past of being 'hot on the trigger' to shut down projects that aren't making them money). I reached out the Parse team with these concerns, and for what it's worth, I received this response:
Thanks for the note. Parse is operating as an independent team within Facebook. The plan is for us to operate autonomously, but to leverage Facebook resources if and when appropriate. As an example, we have hired 4 new team members from the existing Facebook Platform team. Pre-acquisition we would not have been able to add four new heads to Parse in such a short timeframe. There are no plans to shut down Parse. Actually a good example of another acquisition that is operating independently is Instagram. Like Instagram, Parse's existing team remains intact, as does our brand, our website, etc.
We can probably take that with a grain of salt, but it at least seems to be solid for now.
Regardless, I'm going to try out apiOmat in the meantime, as it looks really promising and even more simplified; thanks for the heads-up on that. It seems to be similar to another alternative, which is also promising: Windows Azure Mobile Services. Here is the link to the iOS side of things for that:
Glad to see that there are this many alternatives for this kind of thing, regardless. It's a God-send for us, as it is helping eliminate the need to contract out API/webservice developers for smaller projects that still require a backend.
July 24th, 2013, 03:42 AM
If you can live with idea of being charged for API calls that eventually turns out a very expensive solution, then Parse might work for you. Alternatively, take a look at Backendless. The pricing is a lot more reasonable and the feature set is just as powerful. They have a free tier with unlimited API calls in the free package.
July 24th, 2013, 09:51 AM
You raise a good point. We are planning on updating some apps to use Parse, and the 1-million request limit they have for their free plan sounds like a lot, but I believe that's for EVERY API call. A single user could just be browsing with this app we are planning on building, and easily get up to 10-20 requests in one session. This may not be good, as it could fill up VERY fast for our planned user-base.
Originally Posted by tt700
I looked into Backendless, and I REALLY like the fact that it's scale-able based on your needs, rather than just high-level plans from which to choose. I.e. you only pay for what you want to use. I was concerned at first, because I didn't see any asynchronous options for calls, but I checked deeper into their SDK documentation, and it looks like they do.
A couple questions if you don't mind - I don't see an easy way to upload a photo and "associate it" with a User. Is that possible to do fairly easily with Backendless? I may be missing it in their documentation, but wanted to make sure (I'd be surprised if it's not supported, since this would seemingly be a common thing for a profile image). Also, am I reading it correctly that REST API's are available for the data that is inserted/updated in the backend from the app? This is important for us, since some of our apps require online "dashboards" that connect to (and allow modification of) the data from websites, and we can utilize those REST API's, I'm guessing, for this?
Anyway, I'll keep digging into it, and thank you for the heads-up on Backendless! It's looking like this may be the way we need to go.
July 24th, 2013, 04:26 PM
Quick follow-up - after playing with Backendless a bit, there were some things that struck me as really nice. It's great to be able to map from local objects directly into their DB, and I love the "Pay only for what you use" mentality, of course.
However, there are some not-so-nice things as well. For instance, their SDK methods don't have the option for block-based callbacks! I'm currently reaching out to them to see if I'm missing something there, because that's honestly a potential show-stopper. All SDK's of this kind should really offer API methods that have block-based callbacks. Also, their documentation and support level seems a bit on the "new" side, so it worries me to invest much in this product quite yet.
August 1st, 2013, 09:47 AM
You better reach out to them with details regarding your questions. They seemed to be quite responsive. However, the documentation is indeed rough at best.
August 1st, 2013, 12:03 PM
Yep, to be fair, they are very responsive. I requested they add block-callbacks to their iOS SDK, and they had it done and added to the SDK within days! See the below link for reference:
Originally Posted by tt700
I am very impressed! Although it's probably a bit too early to use them for our big apps and client-based apps, I want to keep a close eye on them to see how the platform grows and matures. I think their scale-able pricing plan is probably the best on the market, so they are definitely worth keeping an eye on.