Public app ecommerce

FREDY_ORTEGON · 06-04-2020 09:49 AM

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?

Austin

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.

FREDY_ORTEGON

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.

Austin

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.

FREDY_ORTEGON

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?

Austin

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.

FREDY_ORTEGON

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?

Austin

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

FREDY_ORTEGON

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?

Austin

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

Austin

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.

FREDY_ORTEGON

remember that security filters do not work in public applications

Austin

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

FREDY_ORTEGON

really?

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

Austin

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

FREDY_ORTEGON

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?

Austin

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().

FREDY_ORTEGON

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.

FREDY_ORTEGON

According to what I am testing, public applications do not support security filters

Austin

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.

Austin

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

FREDY_ORTEGON

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

Bahbus

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.

FREDY_ORTEGON

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 .