First of all, I want to say that I’m personally not a big fan of ecommerce type apps with Glide. There’s a lot of complexity to them and everybody has a different view for how they should work. Because of that, I generally don’t give advice on how to do things with them. Glide has said that ecommerce is not the direction they are focused on and I think Glide is short on some logic and functionality to properly handle the purchase and inventory side of things. With that said, I still made an example to demonstrate a concept that I like to use in some of my apps. I may use some version of this in a production capacity someday, but it is a rough example that I threw together last week. Apologies if some things don’t work as expected. I may make modifications here and there to fit a specific use case I may have. Anyway, a shopping cart just felt like a good way to demonstrate this technique.
The general structure is a shopping app with a Products table that lists the products, a Cart table with a single row that holds the selected items and calculates subtotals for each item, and an Order table that stores each individual order once a user completes their purchase. The products table has a row for each product. The cart table is only one single row that’s shared among all users by using user specific columns. The orders table will grow based on the number of completed orders. Each row in the orders table contains all items purchased with each order along with the quantity for each item. That way a complete order is kept in one row to keep row usage is minimum. I do not have any logic in place to handle the exchange of any money, but it will write a row to the orders table and update the available inventory in the products table once the purchase is complete. I also store information, such as name, address, phone, etc., that is entered during checkout, to the users table so it auto-populates the next time that a returning user makes a purchase. Due to some limitations with glide that I couldn’t work my way around, I am limiting the number of unique items that can be purchased to 20 unique items. The quantity of each item purchased is limited only by the amount available in inventory.
This concept uses the general idea that I introduced in the Reset Multiple Rows At Once concept and that @Robert_Petitto demonstrated here An EASIER and LEANER Trebuchet Method for Multiselect . The additional feature that I added, was the handling of quantity as well as the selection of an item.
Basically, when items are added to the cart, they are marked as selected within the products table along with the selected quantity. This is done by assigning a new Unique ID to the Cart, and then applying that unique id to each selected product. Product price and quantity are also calculated within the products table for a subtotal per item. The cart table then uses the unique id to create a relation to the products table to pull in those selected items, quantities, and subtotals. Then it totals them, adds tax and shipping, and gives a final total. Changes to quantity and product selections can be made dynamically and the cart will update automatically. The magic here, is that there is only one cart row, and a relation between the cart and the products give the illusion that items are being placed in a cart. It’s not until someone completes there order that a new row is written to the orders table and updates the inventory. Once an order is complete or the cart is cleared, then the Unique ID that links the cart to the products changes and breaks that relation, so the cart is essentially empty until a user selects new products to add to the cart. There’s also some other logic to handle items going out of stock if they are already in the cart, but checkout has not been completed.
The other posts that I linked above will give a better idea of how this all works. A lot also happens within custom actions to do different things, such as reset the selected quantity in some cases, or initially set the unique cart id the first time a product is selected.
I tried to design it so a user could add items to the cart and then prompt for them to sign in when they were ready to complete their order. Unfortunately, the sign in overwrote the user specific column values that were stored locally, so the entire cart was lost or reverted to whatever that signed in user may have selected in their prior signed in session. Instead I now require sign in prior to adding an item to the cart. It’s not ideal but good enough for me.
Again, I’m not a big fan of ecommerce apps. I am more interested in demonstrating this concept to show what you can do with glide if you structure your data correctly and get a little creative with how things link together.
Feel free to play around or make a copy to see how it all works.
Enter some fake information and make a second order to see how it pulls in your saved details.
PLEASE DO NOT ENTER YOUR REAL NAME, ADDRESS, OR PHONE.
once more
Superb 
) that eventually you can find here:
