The Digital Archaeology of Final-Project3
How a student's 2015 recipe app captured the 'Big Bang' of decoupled web architecture.

The world is divided into Learners and Non-Learners and I am most certainly a Learner, When I graduated Medical School in 2014 I knew I had no formal education in computer science and so I spent hours learning from online courses to teach myself how to code.
- This repository captures the transition from monolithic Rails applications to decoupled API architectures.
- The developer manually implemented middleware and separate directory structures before frameworks standardized headless development.
- The source code preserves the raw learning process of implementing complex search logic within a relational database.
- Modern web frameworks grew out of the manual boilerplate and configuration struggles seen in these legacy projects.
The Archaeology of a Stack
To understand modern web development, you sometimes have to dig through the strata of abandoned repositories. Final-Project3 is a perfectly preserved technological time capsule from 2015. It represents the exact moment the monolithic web began to fracture. The project is a recipe finder built on Ruby on Rails 4.2 and AngularJS 1.3.
This was an era when Rails was the undisputed king of backend frameworks, but developers were beginning to chafe at its tightly coupled view layer. The creator of the project, Rushindra Sinha, built this application as a capstone project during a career pivot.
The Headless Manifest Destiny
What makes this repository fascinating is its directory structure. Instead of using traditional Rails ERB templates, the code is split abruptly into two folders: /back-end and /front-end. Today, this is standard practice. In 2015, it was a rebellious act.
The developer had to fight the framework to make this work. Rails 5's official API mode was still a year away. This project manually implemented the Rack::Cors middleware to allow the AngularJS frontend to talk to the Rails backend across different ports. It is the story of a developer manually wiring the connections that modern frameworks now handle by default.
The Logic of the OR
The core feature of the application is a search function that finds recipes based on available ingredients. The logic lives in the RecipesController. A close look reveals a classic hurdle in early software development.
def search
# Finding recipes that contain ANY of the selected ingredients
recipe_ids = RecipeIngredient.where(ingredient_id: params[:ingredients]).pluck(:recipe_id).uniq
@recipes = Recipe.where(id: recipe_ids)
render json: @recipes
end
This code executes an 'OR' search. If you select milk and chicken, it returns every recipe containing milk and every recipe containing chicken. Comments left in the source code indicate the developer was trying to figure out how to write an 'AND' search. It is a raw, honest look at the learning process preserved in version control.
From Manual to Managed
Looking at Final-Project3 is a reminder of how much boilerplate we used to write. The project required manual script tags for Angular, custom serializers, and intricate CORS configurations just to get a basic page to render data from a database.
| Feature | The 2015 Way (Final-Project3) | The Modern Way |
|---|---|---|
| Architecture | Manual folder separation | Next.js or rails --api |
| Data Transfer | ActiveModel::Serializers | tRPC or GraphQL |
| Dependency Management | Manual script tags in HTML | npm and Vite |
| Cross-Origin | Manual Rack::Cors config | Handled by framework routing |
Today, frameworks handle the architecture so developers can focus entirely on the product. But those frameworks exist only because developers in 2015 struggled against the old monoliths to build a decoupled future.