Tag: Development Progress

Categories
Capstone Development Progress

We Made It

Well, here we are—the end of the Alpha development cycle for Foodable. And man, oh man, has it been a journey. In this post, let’s talk about the biggest challenges we faced while developing this awesome application. There were a few, but we’ll stick to the top three.

Fully Utilizing Server-Side Rendering (SSR)


First and foremost, making the most of Server-Side Rendering. For those unfamiliar with SSR, it essentially means that data is fetched and processed before the page is delivered to the user—super helpful. My team and I were still learning the ins and outs of Next.js (one of the most popular SSR frameworks for React) and didn’t implement it correctly at first. The worst part? I didn’t realize our mistake until we were about 75% of the way through development. By that point, we had written a ton of code, and refactoring it to properly leverage SSR was a major headache—but absolutely worth it in the long run.

Mixing Up TanStack Query and Zustand

To clarify, TanStack Query (formerly React Query) is a server-state management library, while Zustand is a lightweight client-state management tool. Unfortunately, we mixed these up in the early stages of development, which led to an absolute mess of a codebase—so chaotic that even Professor Roger would be disappointed. Ironically, I realized this issue at almost the same exact time we caught our SSR mistake. Fixing it took a ton of effort, but once we got it right, everything felt so much smoother and more efficient.

Team Communication Issues

Now, what’s a development cycle without at least one team-related problem? I won’t name names, but one of our teammates barely communicated, and the work they did produce was sloppy and poorly thought out. Both my other teammate and I made ourselves available multiple times throughout the term to offer help, yet they hardly took advantage of it. This meant we couldn’t trust them with complex tasks or longer assignments, which ultimately put more work on our plates. Look, I get it—everyone is busy—but when you commit to something and don’t use the resources available to you, then blame external factors, it just shows a lack of care for the project.

Final Thoughts

Despite these bumps in the road, I learned a ton about different technologies and being in a development team. The development process went well overall, and seeing everything come together was incredibly rewarding. If I had to pick the most challenging problem, it would definitely be the combination of SSR and state management mishaps. The way I solved it was by sitting down, carefully analyzing our mistakes, and refactoring the code piece by piece—painful but necessary. All-in-all though Foodable was chosen because we wanted to build something practical, innovative, and useful for real people. So far, it has met expectations. Sure, there were challenges, but overcoming them only made the project stronger. Now, onto the next phase!

Categories
Capstone Development Progress

Winter is Coming, but so is Foodable

Hello 👋,

First and foremost it is cold here in Oregon, starting to feel it in my bones. Besides that though, lets chat about the the progression of Foodable; the application that will make all of our grocery shopping experiences cheaper and easier.

v0.0.1

For v0.0.1, my team and I were like a well oiled machine. We fully setup our testing and development environment. In short, we are using Docker compose to create two containers, one containing the Frontend, created with Next.js, and the other containing the Database, using the latest mongo instance. This development environment allows for fast local testing, and seamless testing in GitHub actions with Cypress, Jest, and Postman. Additionally, initial Clerk.js verification was integrated. All-in-all, the progression to get the v0.0.1 went really well and set the development team up for seamless future integrations.

v0.0.2

This version was about getting a main feature of the application functional. In this case, the main feature we decided to focus on was the main CRUD operations for the user, groceries, and recipes collections. A large component of this was to get the API structure and state management set. What this entailed was figuring out how we are going to use TanStack Query to call our API layer. As of now, we have setup the application to accomplish that task seamlessly and believe that the overall structure between TanStack and our API layer will not need any major changes in the future. Along with TanStack for managing the server-side state, we implemented an initial client-side state manager: Zustand. This will allow us to store the information that we know we are only going to need to retrieve once or at most twice throughout a users session length on the application. TanStack and Zustand were not in the initial architectural designs, however we believe that it will make the overall data management and UI / UX significantly better.

The Struggles

The team and I have agreed that we want to do this application the right way, not just the easiest. For instance, we could have easily used a simple to use database such as Firebase but we chose to use MongoDB to have the flexibility that the application should have. With this being said though, there have been some struggles. All of us have read through a lot of information and documentation about the technologies that we will use and that is time consuming. We all have jobs and busy lives outside of this project, so it can sometimes be hard to balance everything, but together we have persevered and are developing something I think is super cool.

What’s Next?

I am assuming that the next version will be v0.0.3, but you never know. For whatever the new version is called, the progression takes place over winter break. While myself and the team have agreed to work on the project, it will not be the only thing we do. Seeing family and resetting the brain is highly important for life and development. But I still plan to do a good chunk of stuff. For this next version the main things that need to get developed are:

  • Finishing the Role Based Access Control (RBAC) through Clerk.js and connecting that with the MongoDB user collection.
    • This is going to be a little tricky and take some time, but is highly important for the user roles and differentiation in feature access.
  • Creating navigation component for all user roles and screen types
  • Creating UI for all of the pages
  • Connecting TanStack query with front end components

In short, when this is done, we should be able to have a strong user flow for the application, which will allow us to create interviews with users and get feedback on the design.

Final Thoughts

The development of the Foodable application is going pretty well, all things considered. We have a really strong base and good understanding and design about how this application will be developed. Along with this, the members of the team are all now familiar with each other and a sense of trust has grown among us, allowing for good communication and nice development. I have no doubt that this application will be great and we will all continue learning a lot in the process.

Happy Holidays To Everyone!!!

If you have any questions, please feel free to comment below.