Easy Inventory: An Overview of My Final Flatiron Project

The final project at Flatiron offers students the opportunity to develop an app of their own design. Since this typically represents the culmination of all that’s been taught throughout the program, this project is the most ‘complete’ in terms of what it can accomplish — for me, this meant tackling a specific problem.

Given a decade of working in kitchens, I decided to address a common nuisance: taking inventory. A restaurant’s inventory is vital to the success of its operation: it’s used to track food cost; it suggests what needs to be ordered, and when; and it dictates how much of any given dish can be made at any point. Needless to say, with inventory being so crucial, it’s imperative that it’s accurate and easy to manage.

I want to outline this project in three ways. First, the walkthrough will be a narrative step-by-step detailing the various aspects of the program. Next, I’ll briefly cover technologies. Then, challenges that I faced and how I overcame them. And finally, I’ll detail what happens next.

A Walkthrough

Upon logging in, the user is directed immediately to the ingredients page that lists each ingredient and allows for filtering by ingredient category, which might conveniently coincide with where in the kitchen the ingredients would be found. Selecting an ingredient will call up an ingredient window that provides extra information that is editable. If we want to update just the amounts of each ingredient, there’s an easy toggle button that places a numeric form field underneath the ingredient name. Once the number is entered and the field is blurred (the cursor exits the form), a fetch is made to the api and the new amount is updated both on the front end and back.

While this is sufficient for tracking the inventory of an ingredient, the purpose of the app is to simplify the entire process, so one feature I added is the order list generator. When the ingredient is updated, if the new quantity falls below a specific number (which is provided when the ingredient is added) then an order list is generated and the ingredient is placed there. Not only that, but the ingredient is associated with a vendor, and given a suggested amount to order.

Next, with the order list ready, we can use a slider to increase the amount to be ordered across-the-board. For instance, if we know that on Sundays our purveyors won’t be delivering, then we want to order more for Saturday’s delivery, and we can use this meter to order up to three times our recommended par.

After our order quantities are set, we add the ingredient to a vendor’s cart and then can send the order. When the order is submitted, it is sent to the vendor’s email complete with the ingredients and their quantities, but it also creates a new form: the pending order list. The pending order list is where, the next day, the user will accept, accept a different quantity, or reject the order. If the order is accepted, then the inventory will be updated as it adds the accepted amount.

Technologies

I kept this app closely aligned with what was covered in the curriculum, meaning that I built a Rails back end with a sqlite database and used React and Redux for the presentation side. JSON Web Tokens provide user authorization, and EmailJS was a nifty add-on for sending the order list via server-side email.

Challenges

There was no shortage of challenges, that’s for sure. First and foremost was scope. I had a much, much larger vision of what I wanted this app to be, but given the time constraints it became very clear rather quickly that I would have to reel it in a bit. This meant going from keeping track of dishes and their components, as well as raw ingredients, I would have to focus solely on the ingredients; it also meant that I had to sacrifice tracking sales, which in turn meant losing any sales forecasting I had in mind. Scrapping these functionalities was difficult, as was accepting a more limited app, but if nothing else it was an important lesson in prioritization.

Truncating my grandiose vision of an app didn’t just hurt my pride, it complicated my wireframe, too. As I whittled down the app, my proposed layout started to lose its logic. There was no longer any need for a landing page or for many of the controllers and routes I had established. This only forced me to adjust my wireframe a bit, but between that and deleting parts that I had to omit, I faced a pretty significant detour. But, lesson learned: more realistic expectations in the beginning could have saved me time in the end.

One other challenge worth mentioning… I was originally setting updated ingredient quantities to the Redux store, and then upon submitting the updated ingredients, iterating over the store and sending a fetch request to update each ingredient… individually. This was a suboptimal approach, and one that seemed to overwhelm the database as it would lock after a certain number of requests. The solution, which in retrospect was only marginally better, was to update the ingredient quantity immediately, onBlur. It was an expensive solution, but served its purpose. But the very recognition that the solution is still incomplete leads us to the final topic: what happens next.

Looking Ahead

What do I do with this app now? Sure, it’s functional, accomplishes what I’ve set out to do, but that doesn’t mean that it’s finished. The first step is to refactor. I’ve already started this process and have found plenty of room for improvement. Once I’ve omitted redundant and inconsequential code, it will be more manageable for adding features and tackling larger problems. As alluded to in the challenges section, some solutions are simply not ideal. With respect to the ‘solution’ of immediately sending fetch requests for ingredient updates, I want to simplify the process by sending a single batch of data for the back end to manage. With that sorted out, I will look to build out an inventory history, or a backlog of its changes, which, in turn, will allow for predictive ordering functionality. Simply put: I’m looking to improve on the code that exists while adding the features I had originally intended to include.

Thanks for reading, and if you have any questions or ideas, feel free to message me!