Recipedia

Gallery

Key Features

Tech Stack

• Java
• Spring Boot
• MySQL
• React
• Tailwind
• Redux
• Axios
• Postman

Why I built Recipedia

Recipedia started with a very real-life problem: me, standing in front of the fridge, holding a half-used zucchini and wondering what on earth I could make for dinner. I figured, "Why not build an application that helps me figure that out?" The idea was simple: track what ingredients I already have at home and suggest recipes based on that. No more endless Googling or throwing out forgotten leftovers.

I wanted it to feel like a smart little kitchen buddy - one that not only finds matching recipes but also shows what I’m almost able to cook, so I’d only need to buy one or two things, not a full cart of groceries. I was also inspired by a hackathon video I stumbled across where a team had built something similar. That gave me the nudge to try building my own version from scratch, using the tech stack I’d been practicing. It turned into a really fun (and delicious) way to level up my coding skills while solving a real problem I face pretty much every evening.

The process

I kicked things off by setting up a basic Spring Boot backend—nothing fancy, just some classic REST endpoints and a MySQL database to hold my kitchen “inventory.” I wanted the user to be able to add and remove ingredients easily, so I kept the backend clean and straightforward. Once that was rolling, I jumped into the frontend with React and built a no-nonsense UI where users could tick off ingredients they had. I wired it to Spoonacular API fetch recipe suggestions based on those inputs. The goal was to keep it fast, clean, and actually useful. I didn’t want bells and whistles—just a solid helper app that answers the eternal question “What’s for dinner?” To top it off, I added login functionality so users could save their ingredient lists. Because let’s face it, no one wants to re-enter “pasta, ketchup, and cheese” every single time. Around mid-project I got ambitious and added a few goodies: a shopping list, a weekly meal plan, and recipe ratings.

Problems

First off: recipe APIs are picky. Some had limits, some wanted money, and some returned... weird suggestions (like “tuna smoothie,” no thanks). Also, getting the matching logic right was trickier than expected. At one point, it kept recommending recipes that needed one ingredient I definitely didn’t have: “anchovies.” I don’t even like anchovies. Frontend state management also caused some chaos. I’d forget to update the UI when ingredients were removed, so it kept suggesting recipes for stuff that no longer existed in my fridge. Classic. I also did a lot of back-and-forth between backend and frontend—turns out I wasn’t sending a couple of fields the UI actually needed, and a few typoed/mismatched property names (hello, ingredientName vs ingridientName) blew up the frontend until I fixed the contract. But every bug, API hiccup, or design decision taught me something—from better error handling to smarter queries to appreciating how real apps think like real users (even if they don’t like anchovies either).

Lessons learned

• Start small, then spice it up: Trying to build everything at once is like throwing all your spices into a pot and hoping for the best. Starting with basic CRUD and gradually layering in features made everything easier to manage (and actually work).


• APIs are not always your friend: Some APIs play nice. Others ghost you, rate-limit you, or send you recipe suggestions that make you question humanity. Always read the fine print and test thoroughly.


• UX matters, even for dinner apps: Simple, responsive, and friendly beats flashy—plus a single source of truth killed the “ghost ingredients” haunting my pantry list.