Week 1 of senior phase down and I’m right in the thick of our first project: building an ecommerce site, i.e., an Amazon clone. So how does one go about doing this? Well, one does not; that is, we were put in teams of four to tackle this project, for which we were given just over a week. Working in pairs and groups has been heavily emphasized, and I completely understand why: you can only understand a problem once you walk through it, and the best way to walk through a software problem, which is fundamentally a language problem, is to talk through that problem. That, and building an ecommerce site by yourself, in a week, would be pretty intense.
So how did we begin? After initializing a git repo and waffle workflow manager, my team began with an ERD: Entity Relationship Diagram. This helped us walk through our database schema design at a high level prior to writing any actual code. We found we would need (at least) 4 models: Users, Items, Orders, and Reviews. Relationships? Users have many Reviews; Orders belong to many Items; Items have many Reviews and belong to many Orders; Reviews belong to many Items and belong to many Users (*phew*). We found this required a join table: one between Orders and Items, and this relationship proved to be tricky on the backend.
We are using Sequelize, and in order to set the many-to-many associations we had to promisify the setter; however, Sequelize has poor support for this kind of action and does not allow duplicates! So we are currently stuck only able to accept a quantity of 1 per order per item. As it is technically not blocking our MVP, and we have only a week to have a deployable site, we have moved on, leaving that for a (theoretical) circle-back at a later date. In a “real world” scenario, we would have consulted with the product team to confirm MVP requirements, and if it was required we would have had to reconfigure our models, but as it is, we have plenty of other cod to catch.
Another not-a-bug-but-a-feature came up yesterday as I created our cart logic. To do so, I utilized Passport.js (only local strategy for now, OAuth is on the docket for this coming week) and cookie-session (saves session in a client cookie as opposed to backend session store). Passport serializes the user as they login, i.e., places them on the req object for easy access, and cookie-session creates a session and sends the client a cookie in its first response. When the user adds an item to their cart, the server creates a cart array on the session, adds the item to it, and sends it back to the client. The cart then lives on the client side and can be edited by the user at will, whether they are logged in or not. So what’s the problem? Well, if more than one user uses the same browser to shop on our site (I’m looking at you, families), and one of them leaves their cart, even if they log out, the next user will inherit that cart information! Again, similar to the earlier issue, this is non-blocking in terms of MVP but it is something we would definitely need to fix for a production application. (Easiest fix would be to persist the cart in a new model and wipe the cart on user logout, but this would only work for logged-in users.)
Both of these bugs were awesome learning experiences in digging into online conversations on Github and SO. Next week, I’ll tackle OAuth, deploy the site to Heroku, and lastly move on to my hackathon project, a browser-based synthesizer app. Stay tuned!