DEV Community: Rusu Ionut

How I Built rusu-ionut.ro: A Personal Site With Zero Hardcoded Pages

Rusu Ionut — Mon, 19 Oct 2026 14:48:49 +0000

Most personal sites are a handful of pages that you edit in code, rebuild and upload. Mine has no pages in the code at all. rusu-ionut.ro is a small content management system that I built for myself: the pages, menus, blog articles and portfolio projects live in a database, and the site draws whatever the API returns for the address you opened.

This article is the tour I would have wanted before starting: how the site is put together, what is in it, how I keep it from breaking, and the handful of lessons that cost me the most time. The first commit of this rebuild is dated 25 September 2026, and at the time of writing the site is already on version 1.29.

The idea: a site with no hardcoded pages

The rule I started from is simple: a new public URL should be a piece of content, not a code change. If I want a new page I open the backoffice, give it a title, a place in the page tree and a layout, and drop content blocks onto it. No build, no deploy, no pull request.

That rule shaped everything else. Visitors never sign in, because the public side has no user accounts. Only the owner and editors sign in, and only to a separate backoffice. The public site is a read-only reflection of the content.

It is more moving parts than a static site generator, and I will not pretend otherwise. What I get in return is editing from any browser, a real media library, drafts, ordering by drag and drop, and a clean split between content (data) and presentation (components).

The stack at a glance

Front end: Vue 3 with TypeScript and Vite, Vuetify 4 for components, Tailwind CSS 4 for layout and utility styling, Pinia for state, Vue Router, Axios for HTTP, TipTap for rich-text editing and ApexCharts for the dashboard.
Back end: Node.js with Express 5 and TypeScript, Mongoose for the models, Zod for validating every write, Helmet for secure headers and Multer for uploads.
Data: MongoDB.
Tooling: ESLint, Prettier, Husky, Vitest and Playwright.

Two apps, one repository. The layout is deliberately boring:

client/    Vue single-page app (public site and backoffice)
server/    Express API: routes, controllers, services, models
scripts/   Repository tooling
e2e/       Playwright specs that drive the real site

On the server the flow is always the same: a router handles the path, a Zod schema validates the body, a thin controller delegates, and a service holds the business logic. On the client, a view only composes components, composables fetch and shape data, and constants hold every label. I come back to why that matters in the section on rules.

How a page is built

A page is a node in a tree with a path, a layout and a list of blocks. Each block sits in one of four regions: banner, main, sidebar or footer. When you open any address that is not an article or a project, a single catch-all view asks the API for the page at that path and hands its blocks to a renderer. The home page is simply the page with an empty path.

The renderer is a lookup table from block type to Vue component. There are eleven types: free rich text, plus ten widgets (fact cards, skills, timeline, logo grid, certifications, profile card, contact form, blog feed, portfolio list and promo banner).

// simplified: one entry per block type
const componentMap = {
  html: HtmlBlock,
  widget_skills: WidgetSkills,
  widget_timeline: WidgetTimeline,
  widget_blog_feed: WidgetBlogFeed,
  // ...
};

Adding a new kind of block means touching exactly two places: the editor's registry, which tells the backoffice which fields to offer, and this renderer. Keeping the two in sync is a rule, so the editor never offers a block the site cannot draw.

Blocks below the fold are not rendered until they are about to scroll into view, and heavier widgets load on demand behind a small loading bar, so the first screen stays light.

Backoffice page editor with the four regions (banner, main, sidebar, footer) and a few blocks placed.

The add-block picker showing the block types.

The backoffice

The backoffice is a separate part of the same app, with its own shell and its own light and dark switch, independent of the public theme. A short tour:

Dashboard: a chart of how much content there is, a gauge of the average site rating, the latest inquiries, recent sign-ins and a visitors overview.
Search: one box that searches blocks, pages, articles, projects and menu links. It shows the text that matched and, for a block, which pages use it.
Pages, blocks and menus: a page tree, a reusable block library, and header, footer and social menus that reorder by drag and drop.
Media library: uploads with type and size limits, previews, file details and a picker that every editor reuses.
Articles and projects: full editors with cover images, categories, tags, publish dates and a draft switch.
Audience: an inbox for contact messages, newsletter subscribers, ratings and a log of sign-ins.
Settings: owner-only switches, such as taking the site offline for maintenance or showing the ratings widget.

There are two roles. Editors create and update content; owners can also delete things and change settings.

The dashboard with the visitors section visible.

The rich-text editor, and not rewriting your content

Articles and text blocks are written in an editor built on TipTap, with three views: Visual, HTML and Preview. The preview shows the content with the site's own styling, in light or dark.

The detail I am most pleased with is small. A visual editor only understands the markup it was built for; hand it anything else and it quietly drops it on the next edit. So before opening content in Visual mode, the editor checks whether it contains anything it would lose: unsupported tags, attributes or inline styles. If it does, the content opens in HTML mode with a warning, instead of being rewritten behind my back.

The article editor showing the Visual, HTML and Preview switch and the toolbar.

The blog

The blog you are reading is part of the same system. Articles have a cover image, a category, tags, a publish date and a summary. When I leave the summary empty, the site cuts an excerpt from the first lines of the article for the cards.

The list supports search, category and tag filters, and pagination, and every article shows its reading time. On an article page you can change the text size (it only affects the open article and resets when you leave), copy the link, or open a QR code for the page. The article ends with an author card with ways to get in touch.

Article HTML is cleaned before it is drawn, so even if something odd ends up in a body it cannot run a script on a visitor's page.

An article page on desktop, showing the text-size control and the share panel.

The portfolio

Projects have their own cards, which you can view as a grid or a list, and their own pages with the story, the technologies and links to the live site and the source. You can search by name or technology and narrow the list with technology chips. The count updates as you filter, and an empty result offers a one-click way back to everything.

A promo banner block can also spotlight one project on any page: a headline, a short pitch, up to two buttons and a screenshot with a gentle float or tilt. A thin light travels around its border. All of that motion switches off for visitors who prefer reduced motion.

The portfolio list with the search field and technology chips.

A site that feels alive

Visitors get dark by default, with a light switch. Both themes come from one set of colour tokens shared by Tailwind and Vuetify, so a button, a card and a chart never disagree about what "primary" means.

On the first visit a startup splash holds until the page's content has actually arrived, then fades. You see one welcome instead of a welcome followed by a second wait. The home page hero is an illustrated landscape: drifting clouds and a sun by day; stars, shooting stars and fireflies at night; and a cyclist riding along the crest of the hills. Inner pages have a calmer mountain version. Everything animated respects reduced motion.

The unglamorous states are designed too: a friendly 404, a retry page for when something fails to load, a maintenance page, an unexpected-error screen, and a contact form that guides you through a message and confirms that it was sent. A small feedback invitation and a rating dialog collect opinions, and on phones the invitation starts minimised so it never covers the content.

There is also a standalone résumé page that prints cleanly, and an in-app changelog: click the version number in the footer to see what changed and when.

The same home hero in dark and light theme, side by side.

One page at phone, tablet and desktop width, side by side.

Friendly states such as the 404 or the maintenance page.

Findable and shareable

Each page and article has its own title and description, a canonical address, Open Graph and Twitter metadata for link previews, and structured data. The sitemap is generated from the published content, so it never goes stale. On the page itself, sharing is one click away, with a copy-link control and a QR code for moving from a laptop to a phone.

Visitor statistics without the creepy parts

I wanted to know which pages and countries bring people in, without handing visitors to a third-party tracker. The result is a small, built-in counter with a few firm rules:

No analytics cookies, and nothing is written to the visitor's browser.
Only the page path is recorded, with query strings and fragments thrown away. Admin screens, previews and obvious bots are excluded, and Do Not Track and Global Privacy Control are honoured.
Unique visitors are estimated without storing an IP address or a browser signature, and the records expire automatically after a few months.
Countries are worked out locally from a bundled public-domain dataset, so no visitor information is sent to a lookup service.
If collecting a visit fails, nothing the visitor sees is affected.

The trade-off is honesty about accuracy. It is an estimate, shared connections and VPNs blur it, and it only counts from the day it was switched on.

Security, in plain words

I will keep this section deliberately general, because how protection works is not something to publish. The principles are ordinary ones, applied everywhere. Every write is validated against a schema before it touches the database. Anything that renders rich content is sanitised first. Roles limit who can delete or change settings, and the API is throttled. Secrets stay in configuration and never in code, and signing in to the backoffice takes more than a password. Errors leave the API as short codes rather than stack traces, and the backoffice turns them into plain sentences.

Rules, tests and a changelog

A project that grows by a feature a day will rot quickly unless something pushes back. In this repository the pushback is a rulebook, AGENTS.md, that binds every contributor, human or AI assistant. It is long, but the ideas are few:

One source of truth. Colours come from theme tokens, user-facing text from one dictionary, and option values and icon names from a registry of literals. Writing "flat" or "mdi-plus" inline in a template is a violation.
Screens are orchestrators. A new screen only composes smaller components and composables. It never owns the markup of every part.
A fixed file order. Template first, then the script with its sections in a set order, then styles only when Tailwind and Vuetify cannot do the job.
Leave it cleaner. Every change ends with a cleanup pass: dead styles, unused imports, orphaned logic.
Preserve the design. A layout that is already on screen is the design. Fixing one thing must not move another.

Here is what the literals rule looks like in practice:

<!-- before -->
<v-btn color="primary" variant="flat" prepend-icon="mdi-plus">
  Save
</v-btn>

<!-- after: same pixels, every value sourced -->
<v-btn
  :color="UI_COLORS.PRIMARY"
  :variant="UI_OPTIONS.FLAT"
  :prepend-icon="UI_ICONS.PLUS"
>
  {{ LABELS.SAVE }}
</v-btn>

It looks like ceremony until the day a label changes or a button style needs to move, and it is a one-line edit instead of a search through every file.

Tests that look at the real site

Unit tests (Vitest, twenty files today) cover pure logic: text helpers, validation schemas, the visitor-counting rules, the splash screen's timing. The part I care about more is the browser suite: 19 Playwright specs that drive the running site at phone, tablet and desktop widths. The rules for those specs are all there because something went wrong without them:

Every user-visible feature ships with a spec that covers all of its states: loading, loaded, failed and empty. The states are produced by holding, failing or faking the network request, not by hoping the database happens to hold the right data.
Assert on what is painted, not on its wrapper. A box can have the right size while the image inside it is blank.
Wait out the startup splash, because it covers the page while the tests still count the content as visible.
Run each spec at least twice. A flaky test is fixed at its cause, never with a retry or a longer timeout.
Look at the screenshots. A passing assertion behind an overlay proves nothing.

A Husky hook runs lint, formatting, the unit tests and both builds before a commit is accepted.

A changelog people can read

Every finished feature or fix bumps the version in lockstep across the packages and adds an entry to the in-app changelog. That changelog has its own rule: milestones only, written for visitors, in plain language, never describing how something works or what it runs on. It is the one place where the project talks to its readers, so it avoids the internals on purpose. Version 1.29 is summed up as understand your audience, a project spotlight, a page for every project and a rider on the hills.

One more honest note. The rulebook is written for contributors and AI assistants alike, and I do use assistants on this project. The rulebook is what keeps that work consistent, reviewable and verified, whoever or whatever writes the code.

What I learned along the way

Same names, different layers. Vuetify ships helper classes named like Tailwind's (pt-16, justify-start), and they sit in a CSS layer that outranks Tailwind's responsive variants. A sm: override that looks right in the code silently loses. The fix is to write the value that must win as an arbitrary value, such as pt-[4rem].
Hidden is not clipped. A decorative light travelling around a banner's border was wider than a phone's side margin. Masking it hid the light but did not stop it from widening the page, so the home page slid sideways on phones. Each ring now clips its own light.
A test can pass behind a curtain. Playwright counts the content under the startup splash as visible, so an assertion can pass while the screenshot shows only the splash. Waiting out the splash is now part of every spec.
Start-up cost is user-facing. The first visit after a quiet spell is the one that makes the impression. I trimmed what the server does at boot, so heavy libraries now load on first use, and the splash waits for real content to avoid a second wait.
Constraints are a feature. A rule like "no new local constants for values that already have a home" feels slow for a day, and then it pays back every time a label or a colour has to change.

Where to look next

If you want the short version: a Vue 3 front end and an Express API around a MongoDB database, where pages are data, blocks are components, the backoffice is the only place anything is written, and a rulebook plus a real-browser test suite keeps the whole thing honest.

Click the version number in the footer on rusu-ionut.ro to read the release history, browse the projects to see what else I have built, and if you have a question about any of this, the contact page is a message away.

Why I Ditched VS Code for Zed (And How It Accelerated My Full-Stack Work)

Rusu Ionut — Wed, 03 Jun 2026 17:27:00 +0000

For the past few years, VS Code was my comfortable, heavily customized home. It had my extensions, my themes, and a decade's worth of muscle memory. But recently, as my stack evolved heavily into Express.js, Vue 3, and Tailwind CSS, I started noticing the micro-frictions.

VS Code is an industrial powerhouse, but it is built on Electron. Under the hood, it’s running a wrapped version of Google Chrome. When you are deeply indexing thousands of dependencies inside node_modules, running real-time frontend dev servers, and layering on AI code completions, those micro-stutters and cursor lags start to compound.

Two weeks ago, I completely cut the cord and switched to Zed—the open-source, GPU-accelerated code editor written from scratch in Rust.

Here is the real, unvarnished story of why I made the jump, the brutal financial reality check I ran into with token billing, and how this layout shift dramatically accelerated development on my main production project, recipe-finder.org.

The Blazing Speed (The Rust Difference)

The very first thing you notice when you open Zed is that it doesn't "launch"—it just appears. Because it's compiled natively in Rust and uses your computer's graphics card to render text, everything from file searching (Ctrl + P) to global project searching is instantaneous.

When working on the codebase for recipe-finder.org, jumping back and forth between a complex Express backend route and a Vue frontend single-file component used to feel like dragging a heavy cart. In Zed, switching tabs and editing massive lines of code feels buttery smooth. It completely eliminated the cursor lag that used to break my typing flow.

Perfect Out-of-the-Box Tooling for Vue & Tailwind

I was worried that leaving VS Code's massive ecosystem of 50,000+ extensions would break my stack. It didn't.

Tailwind CSS: Zed has native support built right in. As I write utility classes inside my .vue templates, autocomplete popups appear flawlessly. Hovering over a class instantly shows the raw CSS output.
Vue.js: A quick trip to Zed's extension marketplace (Ctrl + Shift + X) to grab the official Vue extension hooked up Volar (the Vue Language Server) seamlessly. Full type-checking, diagnostics, and scoped styling worked instantly.
Express.js: Because Zed indexes node_modules instantly in the background without locking up the editor UI thread, my Node/Express server setup became incredibly responsive to work with.

The Token Price Shock (And How I Fixed It)

If you use Zed’s native AI panel on the right side, you need to understand how it bills. Zed Pro gives you a $5 monthly token credit and then switches to pay-as-you-go raw API costs +10%.

Within my first hour, I burned through $2.63 in just four questions.

I had massive sticker shock until I realized how LLMs work under the hood. It’s called the Context Snowball Effect. Every time you type a follow-up question in the right-hand panel, Zed bundles the entire chat history plus your active code files and flings them back to the model. You aren't paying for small questions; you are paying the AI to re-read your entire file over and over again from scratch.

The Solution: The Ultimate Hybrid Workflow

Instead of paying for metered usage-based billing with Zed-hosted models, I leveraged a brilliant feature built directly into the editor: I plugged in my existing $39 GitHub Copilot subscription.

By pressing Ctrl + Shift + P and running copilot: sign in, I authorized my GitHub account. Then, I switched my right-side AI panel dropdown provider to "GitHub Copilot Chat".

Now, I get the flat-rate predictability of Copilot (ask 500 questions a day, leave massive Vue files attached, no extra fees) combined with the lightning-fast, zero-lag editing environment of Zed. It’s the ultimate setup.

How It Accelerated Recipe-Finder.org

We’ve been sprinting hard to push out a massive referral marketing campaign on recipe-finder.org: a brand-new invite portal titled "Get a FREE Month of Premium!".

This required writing a specialized absolute overlay over our main Vuetify cards to handle asynchronous loading states smoothly. In my old workflow, tweaking the custom Vue deep selectors (:deep(.v-loader)) and alignment styling while waiting for code completions to catch up was tedious.

With Zed docked perfectly to my preferences—with the terminal and project panels pushed over to the right side just like VS Code, and the minimap file preview pinned to always—the cycle time dropped to zero.

<!-- A snippet of the optimized portal cards we shipped under the new setup -->
<template>
  <v-card loading class="premium-invite-card">
    <v-card-title>Get a FREE Month of Premium!</v-card-title>
    <!-- Referral portal components -->
  </v-card>
</template>

<style scoped>
.premium-invite-card :deep(.v-loader) {
  background-color: rgba(var(--v-theme-surface), 0.85) !important;
  backdrop-filter: blur(6px);
}
</style>

The combination of instant file-saving formatting, snappy inline AI predictions, and zero-latency UI rendering allowed us to prototype, style, and ship the invite portal features significantly faster than before.

The Final Verdict

If your engineering workflow depends on hyper-niche VS Code extensions (like complex graphical visual debuggers or proprietary database managers), keep VS Code close by.

But if you are a full-stack developer working in the JavaScript/Node ecosystem, handling reactive frontends, and writing code alongside AI assistants all day, do not sleep on Zed. Connect your existing Copilot key, clean up your layout, and enjoy a text editor that finally keeps up with the speed of your brain.

Have you tried switching to Zed yet, or are you staying loyal to VS Code? Let me know your setup below!

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