This post will show you how to implement a kind of “expiration” for your data objects. The strategy is sufficiently abstract, so it’s applicable to any resource you need to expire, including files, logs, and so on.
Since the database does not have any built-in expiration mechanism, we’ll have to implement it on our own. Fortunately, the task is pretty easy because we have access to Backendless Business Logic. The idea is to create a Timer, which is going to run with some fixed time period and delete the resources based on your criteria.
One of the final steps before you release an app is to setup proper security. Specifically, the security of your File Storage is perhaps the most important since it may contain your business logic code, your public website data, your logs, and any other assets which you probably do not want anyone from the outside to be able to see. This post will provide a few guidelines on how to structure your File Storage with security in mind and instructions on how to set up the permissions properly. The sample use-case will be a bit over-concerned with security, so you most likely won’t need all of this for your specific case, but you’ll be aware of what to do in the worst case.
If you’ve worked with Backendless API for a while, you may occasionally run into a situation where the functionality you’d like to have isn’t readily available. One such function is the programmatic management of your application’s data tables. For instance, you may need to clear up all the data and recreate the table structure with specific columns on demand while developing your app. This article will show you how to do that and more.