How to limit parse.com requests

[Stephen_Lewis]

I’m using parse.com to store a json file that contains a bunch of variables that my game uses.  I can then update these variables while my app is live by simply updating the json file and having my app download the file periodically.

My question is, how can I limit my app to download the file only if the app doesn’t have the latest version?  Currently I have the app request the file each time it starts up or resumes, but this would normally be way too often as I plan to update the file at most once a week.  Since parse costs increase with the number of reqs. i’d like to be smarter about when I download the file.

I guess I need a version number check to sync with, but even checking a single variable would technically count as a req. on Parse.  Do I need to check a version # on my own server or something similar?

Thanks for any help! 

[rob]

Having one on your own server would probably work, but at that point if your going to host that, why not host the JSON file on your own server??

[Stephen_Lewis]

Good point, Rob!  I was originally hosting the file on my own server but since I thought I would be using Parse for user registration and a few other things I thought I should get the ball rolling with file hosting in order to learn how to get Parse set up. But if I need to use my own server to check the file’s sync status I guess there’s no point using Parse for file hosting.

But to my original question, is there a smart way to download the file only when it’s changed that doesn’t require using my own server and doesn’t chew through unnecessary Parse reqs?

Thanks

[rob]

Probably not.  I don’t know much about how Parse deals with files.  On your own webserver however, we now support HTTP’s HEAD operation (I think) with network.request() which should let you fetch the meta data for your file where you can see the last update time without actually downloading the file. Then if you need to you would do a second network.request/network.download to actually fetch the file.

With Parse, it’s going to end up being a request to get any information about the file unless they support HEAD and don’t count that (though I doubt they will do that)

[ksan]

I have an idea but I’m not sure if it will help you reduce Parse requests while also solving the versioning question in a simple manner. I think it might just work.

1. Give your config files sequential names. The first one config001, second config002 etc. 
2. You deploy your app with config001 in it. As soon as it is launched it looks for config002 file name on Parse and if it is present it downloads it. If its not there then you probably will get away without incurring a ‘request’. Not sure though. 
3. If config002 is there and gets downloaded then your app starts to look config003 next time it runs etc. 

Another idea could be to make it so the app does not check for new config at all. When you have a new config you send a push notice out and send the new config as payload. That definitely would reduce the request count but you would end up having to deal with the payload issues etc. 

Best of luck! Regards,

Kerem

[Stephen_Lewis]

Thanks Kerem!  Those are some good ideas worth trying.  

I knew there were some clever people out there 

[ksan]

You’re much too kind. Don’t know much about clever. Lets just say desperate to make things work… 

Please let us know how it turns out with the Parse requests and if you can get away with what you’re doing. All the best.

[SegaBoy]

Just beginning to look at Parse.com for the same type of reasons - I have experimented with Parse’s Cloud Code, don’t know whether that could help and/or whether it would incur a “Request”…

Jen at LadeezFirstMedia has written an excellent series of tutorials that I recommend checking:

http://www.ladeezfirstmedia.com/2013/06/26/tutorial-part-1-cloud-code-integrate-parse-coms-rest-api-with-your-coronasdk-app/

[Stephen_Lewis]

Thanks for the link, SegaBoy.  Those are some great tutorials, especially for someone like me who is still fumbling around in the dark with Parse.  

I’m pretty sure any call to Parse’s Cloud Code would count as a request, but there are a lot of other nifty ideas/use cases in those tutorials.  The push notifications combined with Parse “channels” is especially intriguing.  

[rob]

Having one on your own server would probably work, but at that point if your going to host that, why not host the JSON file on your own server??

[Stephen_Lewis]

Good point, Rob!  I was originally hosting the file on my own server but since I thought I would be using Parse for user registration and a few other things I thought I should get the ball rolling with file hosting in order to learn how to get Parse set up. But if I need to use my own server to check the file’s sync status I guess there’s no point using Parse for file hosting.

But to my original question, is there a smart way to download the file only when it’s changed that doesn’t require using my own server and doesn’t chew through unnecessary Parse reqs?

Thanks

[rob]

Probably not.  I don’t know much about how Parse deals with files.  On your own webserver however, we now support HTTP’s HEAD operation (I think) with network.request() which should let you fetch the meta data for your file where you can see the last update time without actually downloading the file. Then if you need to you would do a second network.request/network.download to actually fetch the file.

With Parse, it’s going to end up being a request to get any information about the file unless they support HEAD and don’t count that (though I doubt they will do that)

[ksan]

I have an idea but I’m not sure if it will help you reduce Parse requests while also solving the versioning question in a simple manner. I think it might just work.

1. Give your config files sequential names. The first one config001, second config002 etc. 
2. You deploy your app with config001 in it. As soon as it is launched it looks for config002 file name on Parse and if it is present it downloads it. If its not there then you probably will get away without incurring a ‘request’. Not sure though. 
3. If config002 is there and gets downloaded then your app starts to look config003 next time it runs etc. 

Another idea could be to make it so the app does not check for new config at all. When you have a new config you send a push notice out and send the new config as payload. That definitely would reduce the request count but you would end up having to deal with the payload issues etc. 

Best of luck! Regards,

Kerem

[Stephen_Lewis]

Thanks Kerem!  Those are some good ideas worth trying.  

I knew there were some clever people out there 

[ksan]

You’re much too kind. Don’t know much about clever. Lets just say desperate to make things work… 

Please let us know how it turns out with the Parse requests and if you can get away with what you’re doing. All the best.

[SegaBoy]

Just beginning to look at Parse.com for the same type of reasons - I have experimented with Parse’s Cloud Code, don’t know whether that could help and/or whether it would incur a “Request”…

Jen at LadeezFirstMedia has written an excellent series of tutorials that I recommend checking:

http://www.ladeezfirstmedia.com/2013/06/26/tutorial-part-1-cloud-code-integrate-parse-coms-rest-api-with-your-coronasdk-app/

[Stephen_Lewis]

Thanks for the link, SegaBoy.  Those are some great tutorials, especially for someone like me who is still fumbling around in the dark with Parse.  

I’m pretty sure any call to Parse’s Cloud Code would count as a request, but there are a lot of other nifty ideas/use cases in those tutorials.  The push notifications combined with Parse “channels” is especially intriguing.  

[jen.looper]

hi, *blush* thanks for the shout-outs. Just passing thru and available if you need any help on the Parse stuff. It really is a fantastic service.

One thing to optimize your api requests (which will indeed start adding up, although the ceiling is pretty high even for the free account) is to chain your queries. I think I need to write a tutorial on this…my sample code ought to be refactored so that, for example, once you login, we don’t make a second request to send an email but rather chain the user registration with the email sending process so that the whole thing is done in one fell swoop on the Parse side, rather than as another network request.

Another thing we ought to be leveraging is Parse’s brand spankin’ new scheduler tool. So your scheduler could be set to run on a daily job on the Parse side to mark any of your files that have changed; your query to fetch the file then could simply grab the file(s) marked as changed automatically.

https://www.parse.com/docs/cloud_code_guide#jobs

I think that the scheduler doesn’t chew up API requests, not 100% sure. Looks like I need to do some more writing

Jen

[bjsorrentino]

Hi Jen,

Can you please let me know when you post a “Part #6” to your Parse.com tutorial series, if you plan to write one? I’ve been linking these up in Corona University, and I don’t want to miss if you add another one before I notice it being there.

http://www.coronalabs.com/resources/tutorials/communication-and-social-media/

Thanks,

Brent

[Anderoth]

I agree with Jen that using something like Parse’s cloud code helps save on requests. I sometimes do up to 4-5 things in a single request before returning to my app. I took a lot of bits and moved it to the cloud. However it will still cost you at least one call.

I would go with something like ksan suggests. Just put a text file on your webserver. Download it as often as needed. You can still use Parse as your user database. The key advantage of these cloud services is they scale to the needs of your apps. If scalability is not a huge concern, doing your own database solution may be better.