Public app ecommerce

I would like to develop a public e-commerce application, where users who download it from stores can enter and view products from affiliated stores. on the other hand I have an administrative application (pay per user) where each store can see their information, add their products and dispatch the orders that users make. My concerns are:

1- What happens in the public application when my data in daily transactions grows?
2- the public application will be slow ?.
3- if I do not store the daily transactions in the public application and use webhook to copy the information to another table (which only allows adding records) this table will slow down the public application being read-only? …

*** In short, how can I prevent my application from slowing down as it grows in users and transactions?

I found this information, but I still don’t know if activating that function (Filter out all existing rows?) and this table grows in records, will my public application slow down?

1.So the problem with public apps is you can’t particularly show that user their history of transactions since you aren’t uniquely identifying that user. This increases the complexity of how you must go about filtering out data.
2.As far as I know public apps are the same speed as private apps of the same size.
3. I don’t particularly follow.

If you use the filter out all existing rows your app will not slow down by adding more records to that table. The speed of the app is mostly determined by how many rows, tables, actions, workflows, and rules are applied to that app. There is a overhead for security filters but I believe this overhead does not apply to the Filter out all existing rows. If possible you should create a historical table that is used in your administrative app and keep only most current records you need to show in the public app.

1 Like

It means that regardless of the records that my order table, order details, stores and registered products may have, the application will not be slow. The projection that I have is a minimum of 500 stores, with 100 products each and to that must be added the orders that users make with the detail of each order. many records would be precessed. Does this mean that the application is not slow?

On the other hand, I plan to filter the data of each user in the public application using a slice with a unique user code that is assigned at the time of registration, this works for now, but my concern is still the size of the records that can be generate.

So if you’re filtering through with just a single field that’s much better than complex filters, then it will get “slower” as you add more rows but the biggest slow factor is the largest table. Appsheet reads tables in parallel so generally the slowest table is the limiting factor of sync time. If the app doesn’t have lots of complex virtual columns and nested actions then performance should be satisfactory. If you have 50k unique products and every user will need to view every product then you will probably be running moderately slow. It’s also a matter of what is slow, is 5 seconds slow or is 30.

1 Like

One solution I’ve been thinking about is the following: I have a table “order detail 1” and another “order detail 2” (with the action Filter out all existing rows? activated) …
“order detail 1” stores the order detail until the user makes the checkout of the purchase, then, it will activate a workflow that deletes the “order detail 1” data and copy the data that was removed in "detail of order 2 “… in this case” order detail 2 "would be the largest table, but it has activated the function of adding data but not showing it. So would this function make this table that is so big become small? do I understand?

That sounds like a decent idea. I would also have a way that the customer selects the store/stores that they are ordering from before they start selecting items that way you can filter down the product table as well.

1 Like

Currently the client selects the store, looks at the products of this store and starts ordering, then users make checkout and at that moment the workflow will be activated, send the order to the mail, change the table order and delete these records in ( order detail 1) to clean the public application … it is still not clear to me if the largest table (order detail 2) has the function of “Filter out all existing rows?” Will the data in this table never enter the public application? In other words, is this function similar to a security filter?

Yes, I believe this setting has additional benefits to performance over say a security filter who’s expression is just “false”.

When you refer to filtering the products of a store, you mean that there is an action called “view products from this store”, containing for example this:

LINKTOFILTEREDVIEW(“Productos”, and([Categoria]=[_thisrow].[id],[Tienda]=[_thisrow].[Tienda]))

This will make the user only see the products of that store of a specific category. Does this cause the app to never call all the 50k products, but only the ones that were executed in the action?

No, this will still pull all 50k products into the app. You would need to have a security filter and some way of tracking what store the user is currently shopping under. Then you would need the product table to be empty if the user is not currently looking at a store to prevent all the products from being pulled. If the products do not have a large number of columns then even 50k rows would not slow the app down a tremendous amount maybe a few seconds

1 Like

So when an app loads, every table is pulled according to the security filter. Even if you never show/use a table it will come in when the app syncs.

1 Like

remember that security filters do not work in public applications

They do work, you just can’t use USEREMAIL()

1 Like


If this has been true, all my life I have been deceived

Ya, you can use security filter to just filter out any data that is not necessary for the app.

1 Like

With this then could using a unique code create the profile of a user and only upload their purchases and everything related to their information?

Yes, the concern is that you cannot verify by any reputable source who this user is. Even if you create unique codes, I can go into your app and type random codes until I find someone where as a private app, I can’t fake my USEREMAIL().

1 Like

a user password could be added. The same if it does not work like this, the important thing is that I can decide what data does not enter my public app and thus play with the performance. In addition, the user’s profile does not store sensitive data, only the purchases it has made.

Heres one of their articles about making public apps and such.


really a thousand thanks for taking the time to help me! I hope I can serve you later.

1 Like