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?
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.
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.
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.
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
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.
remember that security filters do not work in public applications
They do work, you just canโt use USEREMAIL()
really?
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.
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().
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.
According to what I am testing, public applications do not support security filters
I did not at all think about the plan requirements. We are using a business plan which is why I guess we were able to use security filters.
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.
Not in the article is the fact that we now have CONTEXT(โDeviceโ):
While also not perfect, you could ID people solely based off their device ID. The downside being that if the user switches devices they lose any history tied with it, and there would be no good secure way to link the old device ID to the new device ID.
I have a condition for the user to register when adding a product to the cart. at this moment the usersettings field starts with uniqueid (uuid), and this data is saved in the records table. In case the client changes the device and wants to go back to โstart sessionโ, he asks his personal email (with which he made the registration) the unique code with QR to scan it and reconfigure his usersetings, then he will be able to recover his information .
User | Count |
---|---|
38 | |
35 | |
27 | |
23 | |
18 |