Forem: Rusu Ionut

How I built a Social Recipe Extractor that turns short-form video links into structured recipes

Rusu Ionut — Wed, 13 May 2026 15:38:18 +0000

I recently built a feature for https://recipe-finder.org that takes a TikTok, Instagram, or YouTube cooking link and turns it into a structured recipe.

The goal was simple: recipe inspiration lives on social platforms, but the actual cooking steps are usually buried inside captions, spoken instructions, or fast cuts. I wanted a workflow where a user pastes a link and gets back something usable: a recipe title, ingredient list, instructions, and a cleaner format for the rest of the product.

The Flow

The core user journey is straightforward:

The user pastes a supported social video URL.
The frontend sends that URL to a protected backend endpoint.
The backend normalizes the link, fetches available source metadata and text, and runs an extraction pass.
The result is converted into a structured recipe object.
The app returns a clean recipe view, keeps recent imports in history, and can reuse cached results for repeated links.

What makes this interesting isn't just the form input—it's the cleanup step between raw social content and something a user can actually cook from.

Here is a look under the hood at how it's built using Vue 3, TypeScript, and Node.js/Express.

1. Frontend Entry Point

The feature lives behind authentication and opens as a dedicated page in the app. The page itself stays simple and hands the main workflow to a dedicated Social Recipe Extractor component.

To keep the UI predictable and sleek (opting for a dark mode aesthetic with vibrant orange accents for active states), the component manages four main states:

The pasted social link
Loading and error feedback
The extracted recipe result
Recent import history and usage state

This keeps the input on the left, the result on the right, and prior imports available without mixing feature logic across multiple pages.

2. Backend-Owned Extraction Flow

The frontend does not parse social content directly. Instead, it sends the link to a backend route dedicated to social recipe extraction.

That backend layer is responsible for:

Validating the request
Normalizing the URL into a canonical form
Checking whether a usable cached import already exists
Fetching source metadata and extracted text from the target platform
Transforming unstructured content into a recipe-shaped response
Returning a stable payload the frontend can render safely

This is the right ownership boundary because platform parsing, rate control, caching, and extraction quality all belong on the server. The frontend only ever deals with a typed response.

3. Structured Extraction

The most important design choice was ensuring the pipeline doesn't stop at "grab some text from the page." It pushes the output into a highly structured shape:

Recipe title
Prep time
Ingredients
Instructions
Normalized ingredients
Source metadata (platform, thumbnail, title, author)

This matters because a structured result is much easier to reuse than a raw text dump. It allows the data to power future features without rebuilding the extraction logic each time.

4. Normalization and Cleanup

Social content is inherently messy. Titles contain hashtags, descriptions are noisy, and ingredient mentions are often incomplete or informal.

The implementation handles this by cleaning and normalizing content before and after extraction:

URL normalization ensures equivalent links map to the same import record.
Title cleanup prevents social-platform suffixes and noisy text from leaking into the recipe title.
Whitespace and escaped-text cleanup is applied before extraction.
Ingredient normalization makes the output more consistent for downstream product use.

This cleanup layer is where a lot of the actual product quality is realized.

5. Caching and History

Two product decisions make the feature feel significantly faster and more useful:

Cached imports prevent unnecessary repeat processing for the same normalized link.
Import history gives users a lightweight library of recently extracted recipes.

The extractor isn't just a one-shot tool; it becomes a reusable workflow inside the product.

6. Premium-Friendly Usage Model

Finally, the feature returns usage information along with the extraction result. That allows the UI to immediately show whether the user can continue importing, how much of their current allowance is used, and when an upgrade prompt should appear.

This is a much better user experience than hard-failing late in the flow, as the interface can explain the state before the user hits a dead end.

Wrapping Up

This is one of those features where the product value comes purely from reducing friction. People already save recipes from social media. The real improvement is turning that saved link into something searchable, reusable, and easier to cook from.

If I were extending it further, the next logical step would be connecting the extracted, structured recipe directly into grocery list generation, smart meal planning, and nutrition analysis.

Recipe-Finder.org is Officially on Android! 📱🍲

Rusu Ionut — Wed, 13 May 2026 14:56:29 +0000

Hey DEV community! 👋

If you've ever used recipe-finder.org to figure out what to cook with that random assortment of ingredients left in your fridge, I've got some exciting news.

We've officially gone mobile! 🎉

While the web version has been fantastic, we realized early on that dragging a laptop into the kitchen—or trying to keep a mobile browser awake while your hands are covered in flour—isn't exactly the ultimate user experience.

Why We Built the App

Moving from the web to a native mobile environment solved a few core problems for us:

The Kitchen Experience: Native controls allow us to keep the screen awake while you're actively following a recipe.
Quick Access: No more digging through a sea of browser tabs. Your saved recipes and grocery lists are now just a tap away on your home screen.
Better Performance: Snappier ingredient searches, smoother scrolling, and a much cleaner UI optimized specifically for your phone.

Transitioning this project from a web-only platform to an Android application was a great learning experience. (I plan to write a follow-up post doing a deeper dive into the tech stack, the architecture we chose, and the hurdles we faced along the way).

But for today, I'm just incredibly excited to share this milestone with you all!

Give It a Spin

If you're an Android user, you can grab the new app directly from our site here:
👉 Download Recipe-Finder for Android

I'd absolutely love to hear your feedback. If you catch any bugs, have feature requests, or just want to tell me what you're cooking for dinner tonight, drop a comment below!

From Modal to Full Page: How We Refactored a Vue 3 Recipe Detail View

Rusu Ionut — Sun, 03 May 2026 19:51:54 +0000

One of the longest-lived technical decisions in our recipe finder app was showing recipe details inside a dialog modal. It worked — until it didn't. Here's how we migrated from a bloated modal to a clean, SEO-friendly full page, what we cut along the way, and what the app looks like now.

Demo:
https://recipe-finder.org/recipe/644488-german-rhubarb-cake-with-meringue

The Old Approach: Everything in a Modal

The original setup opened a <v-dialog> when a user clicked a recipe card. The modal held the entire recipe detail UI: ingredients, nutrition, videos, AI chef, grocery import, recipe scaler — all of it. The logic for opening it, fetching the recipe, and handling deep-link slugs lived inside HomePage.vue.

<!-- Old: HomePage.vue controlled everything -->
<RecipeDetailsModal :is-open="isRecipeModalOpen" :recipe="selectedRecipeDetails" :loading="loadingRecipeDetails" @close="closeModal"/>

The problem was that HomePage.vue had become a god component. It managed:

The search form and results
Cuisine carousel
Recipe of the day
Recent recipes
And the modal open/close state, slug parsing, and detail fetch

On top of that, because everything was in a modal, the URL never changed. Users couldn't share a link to a specific recipe, Google couldn't index the content, and the Back button did nothing useful.

The New Approach: Dedicated Route + Page

We created /recipe/:slug as a proper route and moved the recipe detail logic into a standalone RecipeDetailPage.vue.

// router/index.ts
{
  path: '/recipe/:slug',
  component: () => import('@/pages/RecipeDetailPage.vue'),
  meta: { title: 'Recipe' }
}

Slugs are derived from the recipe ID and title, making them human-readable and stable:

// utils/index.ts
export const toRecipeSlug = (id: number, title: string): string => {
  const slug = title
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/(^-|-$)/g, '');
  return `${id}-${slug}`;
};

export const extractRecipeIdFromSlug = (slug: string): number | null => {
  const id = parseInt(slug.split('-')[0]);
  return isNaN(id) ? null : id;
};

What We Cut From HomePage.vue

Once the page was independent, we stripped HomePage.vue of everything modal-related. Gone:

isRecipeModalOpen ref
selectedRecipeDetails and loadingRecipeDetails state
The openRecipeModal / closeModal handlers
The slug-watching watch that re-fetched on URL change
The <RecipeDetailsModal> import and component registration
The handleOpenRecipeDetails function passed down through three component layers

The result was HomePage.vue shrinking by roughly 40% in script size. It now does one thing: show the search form and results.

What the Page Layout Looks Like

The page uses a standard Vuetify two-column grid — main content on the left, sticky sidebar on the right (desktop only). On mobile, the sidebar collapses and the tools surface inline.

<v-row>
  <!-- Left: main content -->
  <v-col cols="12" lg="8">
    <v-img :src="recipe.image" cover rounded="lg" class="mb-6" />
    <h1 class="recipe-title">{{ recipe.title }}</h1>
    <!-- chips, rating, action buttons, summary, ingredients, instructions, nutrition -->
  </v-col>

  <!-- Right: sticky sidebar (desktop only) -->
  <v-col cols="12" lg="4" class="d-none d-lg-flex flex-column">
    <div class="sidebar-sticky">
      <!-- Recipe Tools card -->
      <!-- AI Cooking Chef card -->
      <!-- Nutrition Snapshot card -->
    </div>
  </v-col>
</v-row>

The sidebar cards use a glass morphism style that matches the rest of the app:

.glass-card {
  border: 1px solid rgba(255, 255, 255, 0.1);
  background:
    radial-gradient(circle at top right, rgba(255, 163, 92, 0.08), transparent 40%),
    linear-gradient(165deg, rgba(255, 255, 255, 0.07), rgba(255, 255, 255, 0.02));
  border-radius: 16px !important;
}

Mobile: Icon Buttons + Bottom Sheet AI

On mobile, the page can't show a sidebar. We solved this in two ways:

Action buttons become icon-only on small screens, matching how the modal used to look:

<!-- Mobile: icon-only -->
<div class="d-flex d-sm-none gap-2 mb-6 align-center">
  <v-btn icon variant="tonal" size="small" @click.stop="handleToggleFavoriteRecipe">
    <v-icon>{{ isFavorited ? 'mdi-heart' : 'mdi-heart-outline' }}</v-icon>
  </v-btn>
  <v-btn icon variant="tonal" size="small" @click="shareRecipe">
    <v-icon>{{ isCopied ? 'mdi-check' : 'mdi-share-variant' }}</v-icon>
  </v-btn>
  <v-btn icon variant="tonal" size="small" @click="printRecipe">
    <v-icon>mdi-printer</v-icon>
  </v-btn>
</div>

<!-- Desktop: text buttons -->
<div class="d-none d-sm-flex flex-wrap gap-2 mb-6">
  <v-btn prepend-icon="mdi-heart-outline" variant="tonal" class="page-action-btn">
    Add to Favorites
  </v-btn>
  <!-- ... -->
</div>

The AI chef becomes a bottom sheet triggered by a text button inline with the ingredient tools (no floating action button cluttering the screen):

<!-- Ingredient row: Scale / Analyze / Grocery / AI Chef -->
<v-btn color="primary" variant="text" size="small"
  prepend-icon="mdi-robot-excited" @click="showAiSheet = true">
  AI Chef
</v-btn>

<v-bottom-sheet v-model="showAiSheet">
  <!-- full AI interface -->
</v-bottom-sheet>

SEO + Meta Tags

Since the content is now on a real URL, we inject <title> and Open Graph meta tags dynamically on load:

const injectMetaTags = (title: string, summary: string, imageUrl: string) => {
  const pageTitle = `${title} | Recipe Finder`;
  document.title = pageTitle;

  const setMeta = (selector: string, attr: string, value: string) => {
    document.querySelector(selector)?.setAttribute(attr, value);
  };

  setMeta("meta[property='og:title']", 'content', pageTitle);
  setMeta("meta[name='twitter:title']", 'content', pageTitle);

  if (summary) {
    const clean = summary.replace(/<[^>]*>/g, '').trim().slice(0, 155);
    setMeta("meta[name='description']", 'content', clean);
    setMeta("meta[property='og:description']", 'content', clean);
  }

  if (imageUrl) {
    setMeta("meta[property='og:image']", 'content', imageUrl);
  }
};

This is called inside a watch on the recipe computed ref, so it fires on both initial load and when navigating between similar recipes.

Async Components Throughout

Every non-critical UI piece is lazy-loaded:

const ImportToGroceryList = defineAsyncComponent(
  () => import('@/components/ImportToGroceryList.vue')
);
const PremiumUpgradeDialog = defineAsyncComponent(
  () => import('@/components/PremiumUpgradeDialog.vue')
);
const RecipeScaler = defineAsyncComponent(
  () => import('@/components/RecipeScaler.vue')
);
const RecipeEmbedWatermark = defineAsyncComponent(
  () => import('@/components/RecipeEmbedWatermark.vue')
);

The main recipe content renders immediately. The grocery dialog, scaler, embed widget, and upgrade dialog only load if the user actually interacts with them.

Auth Guard on Grocery Import

One regression we caught: clicking "Send to Grocery List" while logged out was calling getAccessTokenSilently() and throwing an Auth0 missing refresh token error. Fixed by checking auth state before opening the dialog:

const onDialogToggle = (open: boolean) => {
  if (open) {
    if (!isAuthenticated.value) {
      dialogOpen.value = false;
      loginWithRedirect();
      return;
    }
    loadGroceryLists();
  }
};

The Result

Metric	Before	After
`HomePage.vue` Script Size	~650 lines	~390 lines
Recipe URL Shareable	❌	✅
Google Indexable	❌	✅
Mobile Layout	Fullscreen modal	Native page with bottom sheet
Auth Crash on Grocery	⚠️ Existed	✅ Fixed
AI on Mobile	Floating button	Inline trigger → bottom sheet

The modal still exists for the recipe list view (quick-peek without leaving the page), but the canonical experience is now a proper page. The code is cleaner, the app is faster to load, and every recipe finally has a real URL.

Built with Vue 3, Vuetify 3, TypeScript, and Tailwind CSS. Auth via Auth0.

Building a Self-Healing SEO Architecture for a Vue SPA

Rusu Ionut — Fri, 01 May 2026 18:18:17 +0000

Building a modern Single Page Application (SPA) with Vite and Vue is great for user experience, but it's a minefield for SEO. We faced three major hurdles:

Aggressive Bot Protection: Our .htaccess was so tight it was blocking crawlers that we actually wanted.
The "SPA Meta Trap": Social media bots (Facebook, WhatsApp) couldn't read our dynamic recipe titles or images because they don't execute JavaScript.
The Scale Problem: We have access to millions of recipes via the Spoonacular API, but we don't own the full database. How do you tell Google about millions of pages you don't physically store?

The Tech Stack

Frontend: Vite + Vue 3 (Hosted on Apache)
Backend: Node.js + Express (Hosted on Firebase Functions)
Database: MongoDB
Provider: Spoonacular API

The Solution: A 3-Step "Self-Healing" Architecture

1. Solving the Social Preview (The Meta Injection)

Since our frontend is on a standard Apache host, we couldn't use edge functions easily. Instead, we optimized our URL structure to include SEO-friendly slugs:

recipe-finder.org/recipe/644488-german-rhubarb-cake-with-meringue

We then implemented a backend-driven meta-injection strategy. When a recipe is requested, our Express server pre-fills the Open Graph tags (og:title, og:image, og:description) using the recipe summary, ensuring beautiful previews on social media.

2. The "Self-Building" Database

We didn't want to scrape millions of recipes (and get banned). Instead, we created an Organic Growth Engine.

Every time a user (guest or authenticated) clicks a recipe, our Express backend performs an Upsert into MongoDB. If it's a new recipe, it's added to our "SEO Index." If it's an existing one, we update the lastViewed timestamp.

// Remove stale entry, then push back to front with a fresh timestamp
await recipeViewedModel.findOneAndUpdate(
  { auth0Id },
  { $pull: { recipes: { id: recipe.id } } }
);

await recipeViewedModel.findOneAndUpdate(
  { auth0Id },
  { $push: { recipes: { $each: [{ ...recipe, viewedAt: new Date() }], $position: 0 } } },
  { upsert: true, new: true }
);

This ensures our database only grows with high-quality, relevant content that users actually care about.

3. The Dynamic Hybrid Sitemap

A static sitemap.xml was impossible for millions of potential links. We built a Dynamic Sitemap Index:

sitemap-main.xml — A static file on our hosting server for core pages (Home, Tools, About).
sitemap-recipes-[n].xml — Dynamic routes on Express that query MongoDB and generate XML on the fly in 50,000-unit chunks.
The Master Index — A central sitemap.xml that bridges the two, served via a silent proxy in .htaccess.

RewriteRule ^sitemap\.xml$ [https://your-region-your-project.cloudfunctions.net/api/sitemap.xml](https://your-region-your-project.cloudfunctions.net/api/sitemap.xml) [R=301,L]
RewriteRule ^sitemap-recipes-([0-9]+)\.xml$ [https://your-region-your-project.cloudfunctions.net/api/sitemap-recipes-$1.xml](https://your-region-your-project.cloudfunctions.net/api/sitemap-recipes-$1.xml) [R=301,L]

Any request for a sitemap is silently routed to the Express API, which assembles the XML from MongoDB on the fly — no static file maintenance required.

The Results

Google Search Console Verified: Live URL testing shows Google successfully rendering the SPA and reading the dynamic content.
Automated SEO: The more our users cook, the larger our sitemap grows. We don't have to manually add a single link.
Zero-Maintenance Scaling: The system handles 10 recipes or 10 million with the same memory footprint thanks to MongoDB's $group and $limit aggregations.

Key Takeaway for CoderLegion

Don't build for millions of pages on Day 1. Build a system that lets your users' activity grow your SEO footprint for you. Work with the bots, not against them.

Author: Rusu Ionut

Project: recipe-finder.org

Get a FREE Month of Premium! 🚀

Rusu Ionut — Sat, 25 Apr 2026 16:36:01 +0000

Hey everyone! 👋

We are excited to share a brand new way for you to enjoy our Premium features. If you've been loving the platform, why not bring a friend along?

Get a FREE month of Premium! The process is incredibly simple: just share your unique invite link, and when a friend upgrades their account, your next month is completely on us. There's no limit to how many friends you can invite!

👉 Grab your invite link here: https://recipe-finder.org/invite-one-free-month

Thank you for being such an awesome part of our community. Happy coding (and cooking)! 💻🍳

Building Recipe-Finder.org: A Full-Stack Journey with Vue, Express, MongoDB, and Vuetify 🍳

Rusu Ionut — Sat, 25 Apr 2026 16:30:34 +0000

Hello, DEV community! 👋

Today, I want to share a project I recently launched: Recipe-Finder.org.

Like many developers, I often find myself staring into the fridge wondering what to make with the random ingredients I have left. I wanted a fast, clean, and intuitive way to search for recipes, so I decided to build my own solution.

It was a fantastic opportunity to dive deeper into full-stack development, and I decided to go with a modified MEVN stack. Here is a breakdown of how I built it, the tools I used, and what I learned along the way.

🛠️ The Tech Stack

I wanted a stack that allowed for rapid development while keeping the application highly responsive. Here is what powered the project:

Frontend: Vue.js. I love Vue for its approachable learning curve and how easily it handles reactive components. It made building the dynamic search interfaces a breeze.
UI Framework: Vuetify. To get that polished, Material Design look without writing hundreds of lines of custom CSS, Vuetify was my go-to. It provided out-of-the-box components like cards for the recipes, navigation drawers, and responsive grids.
Backend: Express.js (Node.js). I kept the backend lightweight. Express handles the API routing, processing search requests from the Vue frontend and communicating with the database.
Database: MongoDB. Recipes are inherently document-like (they have arrays of ingredients, arrays of instructions, etc.). A NoSQL database like MongoDB was a perfect fit, allowing me to store recipe data flexibly without strict relational tables.

🏗️ Architecture & How It Works

The architecture is a standard decoupled setup.

The Client: The Vue app handles all the state management (using Pinia) and user interactions. When a user types an ingredient or recipe name, Vue triggers an Axios request.
The API: The Express server receives this request. It validates the input and constructs a query.
The Data: The server queries MongoDB, retrieves the matching recipe documents, and sends them back as a JSON response.
The Render: Vue takes that JSON data and seamlessly updates the Vuetify DOM components to display the delicious results.

🚧 Biggest Challenges & Lessons Learned

No project is complete without a few bumps in the road. Here are a couple of things that tested my patience and what I learned from them:

1. Managing Complex Search Queries

The Challenge: Users rarely type exact, sanitized ingredient names. Implementing a search that handled both strict array matching (for ingredients) and fuzzy text matching (for recipe titles) was tricky to get right without sacrificing performance.
The Solution: I ended up utilizing MongoDB's text search indexes and the $text operator. For more nuanced ingredient matching, I built out an aggregation pipeline in Express that scores and sorts results based on how many ingredients match the user's input.

2. Responsive UI with Vuetify

The Challenge: Getting the recipe cards to look consistent was surprisingly tough. Recipe images had different aspect ratios, and title lengths varied wildly, which kept breaking my grid layouts on mobile screens.
The Solution: I leveraged Vuetify's v-img aspect-ratio props to enforce uniformity and used the CSS line-clamp property for text truncation. I also fully utilized Vuetify's responsive grid system (cols="12" sm="6" md="4") to ensure the layout degrades gracefully based on viewport size.

🚀 What's Next?

Getting the core functionality of Recipe-Finder.org live was step one. In the future, I plan to add:

User Accounts: So people can save and favorite their go-to recipes.
Meal Planning: A calendar feature to plan the week's dinners in advance.
Smart Shopping Lists: Automatically compiling missing ingredients from a chosen recipe into an interactive checklist.

Let me know what you think!

Building this was a lot of fun, and seeing it live on the web is incredibly rewarding. I'd love for you to try it out!

👉 Check it out here: Recipe-Finder.org

If you have any feedback on the UI, the search functionality, or the code structure, please let me know in the comments below. Happy coding! 👨‍💻👩‍💻

Turn Viral Recipe Videos into Clean Recipe Cards Instantly 🍳

Rusu Ionut — Mon, 30 Mar 2026 21:07:05 +0000

⚡ 60-Second Video -> 1-Click Cooking

We turn chaotic viral cooking videos into organized recipe cards and standardized grocery lists.

Find: Copy a video link (TikTok, Instagram, YouTube).
Paste: Drop it into our extractor.
Cook: Get an instant clean card.

Try it for FREE:

Everybody gets 2 FREE AI imports per month. No credit card required.

👉 Extract Your First Recipe Here

Go Premium for UNLIMITED Imports:

For power users who cook a lot, get seamless, unlimited imports.

👨‍🍳 Go Premium Now

Empty fridge? I built a tool that tells you what to cook 🍳

Rusu Ionut — Wed, 25 Mar 2026 07:39:12 +0000

Hey everyone! 👋

Tired of staring at 3 random ingredients in your fridge and just ordering takeout? Me too. So I built an app to solve it.

Just type in whatever is sitting in your kitchen, and it instantly generates meals you can actually make.

🔗 Try it out here:

🍽️ Find a Recipe Right Now
🧅 Search by the Ingredients You Have
💸 Stop Wasting Groceries

(Dev note: The site is built for lightning-fast searches using Vue 3, Express, and MongoDB).

💬 Let's Talk!

Click the links above, give it a spin, and let me know if it finds you something good.

Also: What is your ultimate "clean-out-the-fridge" meal? Drop it below! 👇

Food #Recipes #Cooking #WebDev #VueJS

I built a Recipe Finder using Vue 3, Express.js, and MongoDB 🍳🚀

Rusu Ionut — Tue, 24 Mar 2026 20:25:05 +0000

Hey Dev Community! 👋

We’ve all been there: you’re staring at a half-empty fridge wondering if you can actually make a meal out of a bell pepper and some leftover rice. To solve my own "what’s for dinner" fatigue, I built recipe-finder.org.

🛠️ The Tech Stack

I wanted this project to be fast, reactive, and easy to scale. Here’s how I put it together:

Frontend: Vue 3 I leaned heavily into Vue’s reactivity system. The goal was a seamless UI where ingredients could be added or removed without any clunky page refreshes.
Backend: Express.js I went with Express to keep the API layer robust yet lightweight. It handles the logic between the user's pantry and the recipe database with minimal overhead.
Database: MongoDB Since recipe data can be pretty unstructured, MongoDB's flexible document schema made it the perfect choice for efficient querying.

🚀 Give it a spin!

I’m officially launching it today and would love for you to check it out:

👉 recipe-finder.org

💬 Let's Talk!

I’d love to hear your thoughts on the UI/UX or any features you'd like to see added. Also, I’m curious—what is your favorite "clean-out-the-fridge" meal? 🍲

WebDevelopment #VueJS #ExpressJS #MongoDB #FullStack #SoftwareEngineering #ProjectLaunch #RecipeFinder