Hi,
Let’s take the use-case where a user can upload a file which only him can see, update and remove. To achieve that, in the current state of the sdk, we need to make 3 call to the API to deny for all users READ, WRITE and REMOVE.
In most case, we should be able to use Roles but why can’t we have something easier ? Still in this use-case, if the owner want to give access to READ and WRITE to another user that would make 5 calls to the API. For each call we still need to check for errors be it sync or async.
Any thoughts on this problem ?
Hi David,
If you use Roles and assign them through console (which you can), you would need to use zero API calls. (perhaps just one, to assign roles to a user).
Regards,
Mark
Hum, I don’t see how I could have a role which would prevent other user to access a file.
Sorry, I forgot that we do not have “Owner Policy” for files, only for data objects. You’re right, you’d need to make multiple API calls, which you can move to a hosted (server-side) service. They would still count as API calls, however, from the client’s perspective, it would make two calls (one to upload, the other to restrict access to the file).
Yeah but I encounter a few problems where the solution is often “Add business logic server-side”, so my question was why can’t there be a method to do that in one call ?
Maybe I’m wrong since I do not know how your architecture works but in my eyes, it doesn’t look like a tricky or complicated feature to add.
my question was why can't there be a method to do that in one call ?
Because this would lead to a very large number of use-cases and thus an explosion of complexity and weight in the SDKs. In addition to that, every single addition to the API must be replicated 6 times (Android, iOS, JS, PHP, .NET, AS), plus tests and doc. As a result, we have to be very selective on what’s added to the API set. The current thinking is to provide elementary building blocks which could be grouped into more complex tasks with custom code.
For now, the SDK already have a method to set the permission but we have to provide which permission we are trying to change. I really can’t see how the number of use-cases or the complexity would explode for such a simple addition taking in account that 75% of the work (use-cases and complexity) is already in the SDK since it should have been done for the existing method.
We get about 30-50 requests every day to make “a little tweak” or add a convenience method here and there. If get on this path, all we’d be doing is expanding the SDK, which is not the core functionality we provide.
That I understand, what I don’t is why these 30-50 requests which aren’t just random requests (at least I don’t think mine are) are disregarded. Making 3 or more calls to one API in the same context with nearly the same action is clearly stupid.
Saying that a cloud code would “solve” the problem is not really that much better, the SDK is how we communicate with the Backend, if it’s not the core functionality of a BaaS I maybe missed something.
I do understand, the difficulties of managing the support of such a service but, unless saying that “cloud code is a good solution” is part of your business model (because like that the 5 free cloud codes are clearly not enough), there should be a list of pending, soon to be added or refused features for the SDK.
Have you tried the cloud code approach? Perhaps you’re overestimating its complexity.
I’m not overestimating its complexity, it’s actually pretty easy to do it with cloud code, what I’m saying is that I shouldn’t HAVE to use it. Even with cloud code, it still is not a good solution since the multiple calls are done server-side.
As you put it in the subject of this very topic “a specific use-case”. It is what it is - a specific use-case. We implement generic use-cases. Specific ones are handled at the application level. I am sorry if you do not like this answer, but that’s where we stand. You’re welcome to modify the SDKs, all of them are open source…
It is a specific use-case only because I didn’t bother to search for other use-cases to make a point.
From what I’ve saw, even with the open-sourced SDK we can’t add new methods, If I could I would have done it.
What I mean is that for this addition you need to make a change to CommLibiOS and since there is only the headers (which is normal) we can’t really add a new feature.
What I mean is that for this addition you need to make a change to CommLibiOS
That’s not true. We never modify CommLibiOS when we add methods. That library is used exclusively for serialization purposes and has nothing to do with the Backendless APIs.
Ok so correct me if I’m wrong, I will take an example for this use-case :
-(id)grantForUser:(NSString *)userId url:(NSString *)url operation:(FilePermissionOperation)operation {
if (!userId)
return [backendless throwFault:FAULT_NO_USER_ID];
if (![self isUrlValid:url])
return [backendless throwFault:FAULT_NO_URL];
NSArray *args = @[backendless.appID, backendless.versionNum, userId, [FileUserPermission grant:url operation:operation]];
return [invoker invokeSync:SERVER_FILE_PERMISSIONS_SERVICE_PATH method:METHOD_UPDATE_USER_PERMISSION args:args];
}
The last line is a call to invokeSync which will invoke this method :
static NSString *METHOD_UPDATE_USER_PERMISSION = @"updateUserPermission";
In order to add a new method I would need to add my new method where “updateUserPermission” is already but it’s not in the SDK.
So did I missed something ?
PS : CommLibiOS is merely the last call that I could follow in the SDK so that’s why I assumed that would need to make changes there too.
To add a new method to the SDK (client-side), you would add it where all other methods are, for example next to this one:
-(id)grantForUser:(NSString *)userId url:(NSString *)url operation:(FilePermissionOperation)operation
As for “updateUserPermission”, it is the name of the server-side method, which has the signature which matches the types and the sequential order of the provided values.
Yeah and in order to implement what I said we need to have a new server-side method.
Which is also counted in the 5 custom business logic scripts which the primary reason of this topic (I’m not here to debate over the pricing).
In order to not have to use a hosted service or a cloud code or whatever, we must make a change in your server-side’s services.