Using Parse.com Android SDK in Java server as opposed to Android app -

we considering use parse.com our database end , looking java sdk parse. far can tell, there two, 1 almonds (https://bitbucket.org/jskrepnek/almonds) , other official android sdk parse (https://parse.com/downloads/android/parse/latest).

we planning make calls out parse java based server (jetty) , not have android app or plan have 1 in foreseeable future.

i leaning towards android sdk since it's official one. however, primary concern performance in multi-threaded environment when used jetty server potentially initiating many requests parse @ same time same or different sets of data.

my other alternative use rest api , write own utilities encapsulate functions. highly appreciate if has experience , can share us. thanks!

i write in january, 2014. parse.com rapidly growing , expanding platform. cannot how long information correct or how long observations remain relevant.

that said...

number one. parse.com charges number of transactions. many small transactions can result in higher cost app owner. using parse.com's pro plan. pro plan has these limits:

• 15 million http requests per month
• burst limit of 40 requests per second

if have 4,500 users, each sending 125 http requests parse.com per day, looking @ 16,850,000 requests every 30 days. parse.com offers higher level of service called parse enterprise. details plan not published.

second, parse.com's intended purpose light-weight back-end back-end mobile apps. believe parse.com mobile backend-as-a-service (mbaas - link forrester article on subject).

i building server-side application using parse.com. use rest interface, cloud functions, , cloud jobs. in opinion, parse.com clumsy application server. not expose powerful tools manipulate data. example, way drop table clicking button in parse's web data browser. example parse sets type of attribute when object first saved. if data type changed in object, string pointer, parse.com refuse save object.

the cloud function programming model build on node.js. complex business logic land in callback hell because database queries , save operations asynchronous. is, when save or query object, hand parse function , "when save/query complete, run function". might come naturally lisp programmers, not oo programmers raised on java or .net. aware of if intend write cloud code application. productivity took nose dive when started writing cloud functions.

the biggest challenge experience parse.com round-trip-time. here informal benchmarks:

getting single object via rest api has pretty consistent rtt of 800ms

• get https://api.parse.comapi.parse.com/1/classes/element/xe5szcqd6d
• response: status=200, round trip time=0.846

icmp blocked, knocking on door takes 400-800 ms, depending on day.

• get https://api.parse.comapi.parse.com/1
• status=404, round trip time=0.579

parse.com in amazon's data center in northern virginia. used ookla's speedtest estimate latency area. reaching richmond business center server (75.103.15.244) in ashburn gives me ping time of 95ms. server in d.c. gave me ping time of 97 ms. 2 hundred milliseconds of internet overhead not problem.

the more queries or save operations cloud function performs, longer response time. cloud functions 1 or 2 queries or save operations have rtt between 1 , 3 seconds. cloud functions multiple queries , save operations have rtt between 3 , 10 seconds.

http requests sent parse.com time-out after 15 seconds. have cloud function use testing deletes objects in database. cloud function can delete couple hundred rows before timing out. converted cloud function cloud job because jobs can run 15 minutes. job deletes 400-500 objects , takes 30-60 seconds complete. job status available through web browser. had create light-weight job status system other devs query status of jobs.

parse's best use case iphone developer wrote game , needs store user's high scores, knows nothing servers. use parse strong.