Collection/Database Permissions - Optimizing for Performance & Security

Hi

Let me preface by saying I’m not a coder. My question is about how to implement permissions in database and editor to improve performance - whether its better to only implement read, write and update controls only in database to reduce the logic processing on the front-end while the app is running.

Because I read this on Adalo help docs Collection Permissions - Adalo Resources

“Updating collection permissions is different from just hiding this information from users by using visibility rules. Instead of just hiding the information, the data is not even served to the users device from the database.”

and I don’t know what “Data is not even Served” means 100% clearly. But I currently assume that these records in the collection are not even fetched, so they appear on the ‘Screen’ on the PWA/Native App pre-filtered from the DB.

Since I’ve read many threads on forum which say we should try to minimize filters, minimize number of collections items fetched, and reduce conditional visibility components on screens to improve performance.

Maybe someone technical can explain where the ‘filtering’ delay really happens in Adalo - DB level or in device’s front-end processing.

Lets take an example of an app I’m working on - a simple app to help users organize their podcast notes. Collections structure is -

  1. Users
  2. Podcasts
  3. Episodes
  4. Notes

Users have many podcasts → 1:m (all their own, not a global standard podcast library from where users follow or unfollow, in which case it’ll be m:m)
Podcasts have many episodes → 1:m
Episodes have notes : 1:1, but implemented in Adalo as 1:m

I want the User Flow to be Home screen (list of podcasts) → Podcast Screen (list of episodes) → Episode Notes. I could do this in Editor by showing a list of podcasts and filtering by logged in user, then list of episodes filtered by current podcast, and notes filtered by current episode’s notes.

Q1) Would my app be faster if I DON’T implement the filters in the Editor, and just show the lists on screen as is, and implement collections permissions - who has access to view, who has access to create, who has access to update & delete - by selecting ‘Some Logged In Users’ and filtering Users further in that?

Q2) Is there a security risk if I don’t implement filters on both “front-end” and databse permisison - as in somehow users who should not be seeing other users’ lists will somehow be able (by accessing Deep Links on PWA or otherwise) to see and modify?

Q3) Or is the best approach to implement filters on both collection permission and in the Editor? Sacrifice a litte performance for optimal balance with security.

This is a trivial use case, but I’m wondering whether this approach will work for more complex use apps like multi-tenant SaaS, project management tools, etc. and help speed up the performance.

Thanks.

Can someone help? Any thoughts?

Keep it using filters, it’s better and has more flexibility.

As long as you give your user the ability to update records, or have them see the records, there is no risk. Make sure you well develop the process.

No, filtering and permission has nothing to do with each others.

Thanks @njimmy10 !

Will implement this way

1 Like

Exactly what you said, the filtering would happen on the Server side, so not on the app, so by default it is more secure, before being sent to the frontend of the APP, by filtering in the APP itself, it needs to load the database first and then filtering is done on the frontend with filtering (Also called as Client side).

Yeah @JL_LJ that was initially my thought process. What you wrote has made my mind clearer.

Forgive the longer explanation, as I’m not technical I want to make sure my point is coming across properly.

Critical part of performance of my app is proportional to how long it takes data to load on my screen.

Step 1. From almost every serious thread on this forum, everyone recommends to fetch limited records from database so as to not slow down the app and make performance worse. So ideally, fewer records requested and fetched = faster performance.

Step 2. Roughly,
Performance ~= Server Side (Fetch request + Filtering done on Adalo’s Servers) + Client Side (Receive records + Filtering done on user’s machine : laptop, mobile, etc.).

Servers will be faster and more powerful, so the major limiting factor will be how fast is filtering on client side machines. So Performance is proportional to Client Side Processing, if I can throw majority of the processing burden to the server side.

From 1 and 2, in order to improve performance of my app what I’m asking is -

  1. especially to load a collection which is bound to become larger and larger in size over time, is it just better to have server-side Filtering done via ‘Adalo Collection Permissions’ ONLY, and not do any client-side Filtering via ‘Adalo Editor’ Filtering?

  2. is it going to be secure having only ‘collection permissions’ and no ‘editor filter’?

I understand this is only applicable in certain cases and collections, because ‘Editor’ filters are so much more powerful and flexible to get the right criteria.

But as I said earlier, I want to understand whether this can be done for collections which I know are going to be growing in size, and so relying on Adalo’s servers to optimize the performance rather than my user/client’s machines.

I can devise the USER FLOW / Screens and Database Structure of my apps in such a way that on initial screens the collections fetched and that most of the processing is done in server side without any ‘editor’ filtering, then once relevant data is correctly passed to subsequent screens, then I can implement more complicated ‘Editor’ filters because that logic is only being performed on limited number of specific records, and speed will not be that much of an issue.

I made a rough drawing to explain my point with the help of the Podcast App in my first post above. Hope this helps in answering my query.

Thanks to @njimmy10 and @JL_LJ again.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.