The First Iteration: A CLI Tool

Before Recipe Strainer had a sleek web interface, it lived entirely in the terminal. The first version wasn't pretty, but it was powerful. It was a Command Line Interface (CLI) tool written in Java, born out of a weekend coding sprint while my daughters were napping.

Why CLI?

Starting with a CLI allowed me to focus purely on the logic. I didn't have to worry about CSS, responsive design, or browser compatibility. I could just focus on the backend architecture:

• Fetching data from recipe APIs.
• Parsing JSON responses.
• Implementing the filtering algorithms that would eventually become the core of our search engine.

How It Worked (and Didn't)

The user would run the program and be prompted with text-based questions:

Enter ingredient to search: chicken
Min protein (g): 30
Max calories: 600

The tool would then churn through the data and print out a list of matching recipes directly to the console. It was raw and utilitarian. I remember proudly calling my wife over to the computer. "Look!" I said, pointing to a block of white text on a black background. "It found a chicken recipe with exactly the macros we need!"

She stared at the terminal window, then at me. "That's great," she said, "but where's the picture? How do I know if it looks good? And I'm not going to type commands into a black box while I'm cooking."

Lessons Learned

She was right, of course. While the CLI was great for testing the data processing, it was completely impractical for daily family use. It wasn't accessible, and visualizing food without images is... unappetizing. However, the core logic I built during this phase became the backbone of the web application you see today. It proved that the concept worked, paving the way for the next big step: building a real interface that my wife—and anyone else—would actually want to use.