Forem: Heron Developer

NutriTrack — How I Built a Full-Stack Nutrition Tracker with React, Supabase & Real Food Data

Heron Developer — Fri, 13 Mar 2026 17:19:24 +0000

👤 Who am I?

I'm a self-taught developer from Brazil, still learning and building things that I actually want to use. I've been studying web development for a while and decided it was time to build something more than a to-do list.
NutriTrack started as a weekend side project with one goal: stop guessing what I was eating. I wanted to know exactly how many calories and how much protein was in my daily meals — without paying for a subscription app, without dealing with a bloated interface, and without manually searching for every single food item.
So I built it. From scratch. With the stack I was learning.

The Problem I Was Trying to Solve 💭

If you've ever tried to track your nutrition seriously, you know the pain. Most popular apps like MyFitnessPal are either behind a paywall for the features that actually matter, or they have a database focused entirely on American/European products — leaving Brazilian foods either missing or wrong.
I wanted something that:
• Works with real Brazilian supermarket products
• Lets me add custom foods manually when the database doesn't have what I need
• Shows my daily progress clearly — calories in vs. my goal, protein in vs. my goal
• Lets me plan meals ahead of time, not just log them after eating
• Doesn't require me to carry my phone into a grocery store just to scan a barcode

That's NutriTrack. A nutrition control system designed around how Brazilians actually eat and shop — but flexible enough to work anywhere in the world.

What is NutriTrack? 📊

NutriTrack is a web application where you build your personal food bank, log what you eat each day, set daily nutrition goals, and schedule your meals for the next two weeks. It's connected to a real food product database so you don't have to type nutritional values by hand for every item.
Think of it as your personal nutrition control panel, not a social app, not a fitness tracker, not a recipe generator. Just clean data about what you're putting in your body — and how it compares to what you set as your target.
The core idea: if you can see exactly what you're eating and compare it against a goal you set yourself, you naturally start making better choices. No coach needed.

Features — and why each one matters

Social Login (Google & GitHub)

The first decision was: no passwords. Nobody wants to create yet another account with yet another password to remember. With Supabase Auth, I plugged in Google and GitHub OAuth in about an hour. 🔐
Every user gets a unique account. All your food data, your daily logs, your goals — completely isolated from everyone else. If someone else signs up with a different email, they see absolutely nothing of yours. This is enforced at the database level using Row Level Security (RLS) in PostgreSQL, not just in the frontend code.
One interesting behavior worth knowing: if you log in with both Google and GitHub using the same email address, Supabase treats them as the same user — which is actually correct. You're the same person. Your data follows you regardless of how you log in.

Personal Food Bank

This is the foundation of the whole app. Before you can log anything, you build your personal food bank — a list of all the foods you regularly eat. Think of it like your pantry catalog. 🥗
For each food item you can store:
• Name and brand
• Calories, protein, carbohydrates and fat per serving
• Serving size and unit (grams, ml, units, tablespoons — whatever makes sense)
• A product photo (uploaded directly to Supabase Storage, or imported automatically)

The key feature here is the Open Food Facts integration. Instead of manually typing the nutritional table from the back of a package, you search the product name and the app hits the Open Food Facts API — a crowdsourced database with over 3 million products worldwide, including a strong Brazilian catalog.
Search for 'Feijão Kicaldo', 'Aveia Quaker', 'Whey Gold Standard', or any product you find at Pão de Açúcar, Carrefour or Atacadão — and it comes back with the full nutritional info and even the product photo. One click and it's in your food bank.
For foods that aren't in the database (homemade meals, restaurant dishes, that specific açaí bowl you get every Sunday), you can add them manually with your own estimated values.

Daily Plan — Your Nutritional Diary

Every day you log what you actually ate. You pick a food from your food bank, select the meal type, enter the quantity in grams (or whatever unit you set), and the app calculates everything instantly. 📅
Meals are organized into categories:
• Café da Manhã (Breakfast)
• Almoço (Lunch)
• Lanche (Snack)
• Jantar (Dinner)
• Pré-treino (Pre-workout)
• Pós-treino (Post-workout)

At the top of the page you see your daily totals in real-time: total calories consumed, total protein consumed, and a progress bar showing how far you are from your personal goal. If your goal is 2,500 kcal and you've eaten 1,800, the bar shows you're at 72%.
One technical decision I'm proud of: when you log a meal, the app saves a nutritional snapshot at that moment. This means if you later edit the food item (say, you got a more accurate calorie count for that food), your past logs are not affected. Your history is always accurate to what you actually tracked at that time.

14-Day Scheduling

Beyond logging what you already ate, NutriTrack lets you plan ahead. The scheduling page shows a 14-day grid where you can build complete meal plans for future days. 📆
Each day card shows the planned total calories and protein at a glance. Open a day and you see every meal broken down: what's in breakfast, what's in lunch, how many calories each section adds up to.
The killer feature: the "Apply to Today" button. Built your perfect Monday meal plan? Hit that button and all those meals are instantly added to today's daily log. No re-entering anything. Your plan becomes your diary.
This is especially useful if you eat similar things on a routine — athletes, people doing a cut, anyone with a structured nutrition protocol.

Personalized Daily Goals

Not everyone has the same needs. A 70kg person trying to maintain weight has different calorie targets than a 90kg person trying to build muscle. NutriTrack doesn't impose default values — you set your own targets. 🎯
You define your daily goals for:
• Total calories (kcal)
• Total protein (grams)

The daily plan page then shows your progress as a percentage of those targets. It's simple but it changes how you interact with food — you stop thinking in absolute numbers and start thinking proportionally. 'I'm at 60% of calories but only 35% of protein — I need a higher-protein dinner.'

Nearby Stores Map

A bonus feature that actually comes in handy: find supermarkets and pharmacies near your current location. This uses GPS from your browser, the OpenStreetMap database, and the Overpass API — completely free, no API key needed. 🗺️
You can filter by store type (supermarket vs. pharmacy), radius (from 500m up to 60km), country, and city. The country and city filters are smart: they detect location by GPS coordinates, not by street name — which matters a lot in border regions. The app correctly separates cities if they border other countries ones, even though they're all within a few kilometers of each other.
The city filter also normalizes variations: 'City Two', 'City two', 'city Two' all collapse into a single filter option showing the most common written form.

Tech Stack — and why I chose each piece

Technology / Role / Why this over alternatives 🛠️
React 18 + Vite Frontend SPA / Instant HMR, zero config, I know the ecosystem
Tailwind CSS / Styling CSS variables for theming, no class conflicts
Supabase / Backend + Auth + DB + Storage PostgreSQL + OAuth + file storage in one free tier
React Router v6 Client-side routing / Declarative routes, no page reloads
Open Food Facts API / Food product database / Free, 3M+ products, strong Brazilian catalog
OpenStreetMap / Overpass / Nearby stores map / Completely free, no API key, global coverage

The most important choice was Supabase. I initially considered Firebase, but the fact that Supabase uses real PostgreSQL was a dealbreaker in its favor. I wanted proper relational tables, real SQL queries, and Row Level Security — none of which Firebase offers in a clean way. The free tier is generous enough for a personal project, and the dashboard is one of the best developer experiences I've used.
For the frontend build tool, Vite over Create React App was a no-brainer in 2024. CRA is essentially deprecated. Vite's startup and HMR speeds make development feel instant.

How the Architecture Works

The db.js layer — single source of truth for database access 🏗️
Every single database operation goes through a central file called db.js. This file has one job: get the current user's ID from the active session and attach it to every query.
Why does this matter? Early in development I had a bug where data from one account would bleed into another account's view when switching sessions. The root cause was that some queries were built when the component mounted — capturing the old user ID in a closure — and not re-evaluated when the auth state changed.
The fix was to make every query call getUid() at execution time, not at component mount time. Now it's impossible to accidentally query another user's data because the user ID is always fetched fresh from the active session right before the database call.

Row Level Security — the real security layer

Even though the frontend always filters by user_id, the real security lives in the database. Every table in Supabase has RLS policies that look like this:
SELECT: only return rows where auth.uid() = user_id INSERT: only allow if auth.uid() = user_id UPDATE: only allow if auth.uid() = user_id DELETE: only allow if auth.uid() = user_id
This means even if someone bypasses the frontend completely and hits the Supabase API directly with a crafted request, they cannot read, write, or delete another user's data. The database itself rejects it.

Nutritional snapshots — immutable history

When you log '150g of chicken breast' on a Tuesday, the app saves the nutritional values as they were at that moment: snap_calories, snap_protein, snap_carbs, snap_fat. These are stored directly in the log row.
Later, if you realize the chicken breast entry had the wrong protein value and you update it, your Tuesday log is not affected. Your historical data is always accurate to what you actually tracked at that time. This is especially important for people tracking over months.

Things I Learned Building This

The PKCE vs Implicit flow OAuth bug 💡
When I first set up Google and GitHub login, I got mysterious 401 errors after the OAuth redirect. The issue: Supabase's default PKCE flow generates a code_verifier and stores it in localStorage before the redirect. But in localhost development, that storage gets wiped during the OAuth redirect, so when the app tries to exchange the code for a token, the verifier is gone.
The fix was switching to implicit flow in the Supabase client config. Not ideal for production at scale, but perfectly fine for this use case — and it made OAuth work reliably.

Account linking by email

Supabase (and most OAuth systems) link accounts by email. If your Google and GitHub accounts share the same email address, they're treated as the same person — same user_id, same data. This is the correct behavior from a UX perspective: you don't want to lose access to your data just because you chose a different login button.

OpenStreetMap data is collaborative — and messy

The nearby stores feature uses OpenStreetMap via the Overpass API. OSM data is crowdsourced, which means it's incredibly broad but not always accurate. A hotel that sells groceries might be tagged as shop=convenience. A car wash near food stalls might appear in results.
I built a filtering layer with a blacklist of OSM tags (tourism, leisure, historic, natural) and a keyword blacklist for store names (hotel, hostel, pet shop, bazar, etc.) to remove clearly wrong results. It's not perfect — OSM data will always have noise — but it's much cleaner than raw results.

City name normalization

The city filter for nearby stores receives raw strings from OpenStreetMap: 'City Two', 'city two', 'city Two', 'CITY TWO' — all referring to the same city. Without normalization, the filter showed the same city four or five times.
The solution: normalize everything to lowercase without accents as the grouping key, but display the most frequent raw variant as the label. So the user sees 'City Two once in the filter, but clicking it matches all stores regardless of how their city was typed in OSM.

Why this works specifically for Brazil 🇧🇷

Brazilian nutrition apps have historically been either underfunded local products or translations of American apps that don't know what 'pão de queijo' or 'cuscuz nordestino' is.
NutriTrack hits the Open Food Facts API which has a surprisingly solid Brazilian product catalog, major supermarket brands like Kicaldo, Quaker BR, Olvebra, Nestlé BR, and hundreds of regional brands are all there with correct nutritional values in the Brazilian format (kcal per 100g, as required by ANVISA labeling).
For foods that aren't in the database, the manual entry is designed to be fast. You don't need to fill in 20 fields. Name, serving size, calories, protein — that's enough to get going. Carbs and fat are optional.
The nearby stores feature knows about the Brazilian territory, app interface is in Portuguese, all meal names, labels, buttons, and messages are localized for a Brazilian audience.

Database Structure (4 tables, all with RLS)

Table / What it stores Key design decision 🗄️
food_items / Your personal food catalog / One row per food. All macros stored per serving. Photo URL optional.
daily_logs / What you ate each day / Nutritional snapshot columns / freeze values at log time. Logs never change when you edit the food.
scheduled_plans / Meal plans for future dates / References food_items by ID. When plan is applied, it creates daily_log rows with fresh snapshots.
user_goals / Your personal daily targets / One row per user. Upserted on save. Defaults to 2500 kcal / 150g protein if not set.

The Project is Open Source

NutriTrack is fully open source under the MIT license. If you want to run it yourself, everything is in the repo — including the full SQL schema to set up the Supabase database, a .env.example with the required variables, and step-by-step setup instructions in the README. 🔗
It runs locally with npm install && npm run dev. Deploy to Vercel takes about 5 minutes: connect the repo, add the two environment variables (Supabase URL and anon key), and it's live.
One important Vercel step most tutorials skip: after deploying, go back to Supabase → Authentication → URL Configuration and add your Vercel URL to the Redirect URLs list. Without this, OAuth login will fail in production.
If you find it useful, build something on top of it, or spot something that could be better — pull requests are welcome.

Developer

🐙 github.com/devheron/NutriTrack

🌐 https://nutri-track-seven.vercel.app/

🚀 How I Built My Developer Portfolio with Next.js, GitHub API, DEV.to API + Trilingual Support and AI Chat in future

Heron Developer — Wed, 11 Mar 2026 21:05:35 +0000

Who's me?

I'm a self-taught developer still learning, and a few weeks ago I decided it was time to stop putting it off and actually build my portfolio.

💡 Inspired by: Portfolio with Gemini — Simple, Smooth, Subtle by @aldwin160. That post showed me how to approach the AI chat feature with a good system prompt. Highly recommend reading it.

Why I built this?

I had been studying web development for some time, and noticed that many developers had already built their portfolio models, so based on that, I decided to make mine, a complete portfolio of information for those who understand it. With the help of Next.js and Tailwind CSS frameworks with applications: API integration, server-side routing, TypeScript, animations, i18n.

✨ Features

Before diving into the code, here's what the final portfolio does:

🌍 Trilingual ── PT 🇧🇷 / EN 🇺🇸 / ES 🇪🇸 with a navbar language switcher (saved in localStorage)
🌙 Dark / Light mode toggle
🐙 GitHub API ── live repos, commit count, follower count in the Hero section
✍️ DEV.to API ── posts fetched automatically, zero token needed
📬 Contact form via EmailJS (no backend needed)
🤖 Chat Assistant ── smart static responses in 3 languages, with Gemini AI ready to activate
📱 Fully responsive ── built mobile-first with inline styles + CSS variables

🛠️ Tech Stack & Why I Chose Each

Tool and Why

1. Next.js 14 (App Router) ── Server components, API routes, file-based routing — all in one
2. TypeScript ── Caught so many bugs at compile time instead of runtime
3. Tailwind CSS ── Utility classes are fast, but I ended up using CSS variables + inline styles for reliability
4. Framer Motion ── The animation presets made scroll animations trivial
5. GitHub API ── Free, well-documented, no special setup for public repos
6. DEV.to API ── Completely public — no token, no account needed to read posts
7. EmailJS ── Contact form without needing my own email server
8. Google Gemini ── Free tier, easy API — integrated but commented for now (rate limits)

📁 Project Structure

porfolioFull/
src/
├── app/
│ ├── globals.css
│ ├── layout.tsx # fonts, metadata, providers
│ ├── page.tsx # mounts all sections
│ ├── favicon.ico
│ └── api/
│ ├── github/
│ │ └── route.ts # server-side proxy (hides token)
│ ├── contact/
│ │ └── route.ts # EmailJS server-side
│ └── chat/
│ └── route.ts # Gemini API route (ready to activate)
├── components/
│ ├── sections/ # one file per page section
│ │ ├── Hero.tsx
│ │ ├── About.tsx
│ │ ├── Skills.tsx
│ │ ├── Projects.tsx
│ │ ├── Posts.tsx
│ │ └── Contact.tsx
│ ├── Navbar.tsx # with language switcher dropdown
│ ├── Footer.tsx
│ ├── ChatWidget.tsx # floating AI chat
│ └── ThemeProvider.tsx # dark/light context
├── data/
│ ├── portfolio.ts # ← only file you edit: your info, skills, projects
│ ├── i18n.ts # all PT/EN/ES translations
│ ├── LangContext.tsx # language context + localStorage
│ └── staticChat.ts # static chat responses by language
├── hooks/
│ ├── useGitHub.ts # fetches profile, repos, commits
│ └── useDevTo.ts # fetches your DEV.to posts
├── lib/
│ ├── github.ts # GitHub API functions
│ ├── devto.ts # DEV.to API functions
│ └── motion.ts # Framer Motion
│ └── utils.ts
└── types/
│ └── index.ts # TypeScript interfaces
└── etc/
│ └── .env.local #env
│ └── .gitignore
│ └── .components.json
│ └── eslint.config.mjs
│ └── next-env.d.ts
│ └── next.config.ts
│ └── package-lock.json
│ └── package.json
│ └── postcss.config.mjs
│ └── README.md
│ └── tailwind.config.ts
│ └── tsconfig.json

The separation makes sense once you understand the roles:

sections/ — page UI, one component per visual section
data/ — your content and translations, no UI logic
lib/ — pure functions that talk to external APIs
hooks/ — client-side data fetching with loading/error states
api/ — server-side routes that hide secret tokens from the browser

🐙 Integrating GitHub & DEV.to APIs

DEV.to — Zero config
The DEV.to API is completely public for reading articles. No token, no account, just fetch:

// src/lib/devto.ts
export async function getDevToPosts(username: string): Promise<DevToPost[]> {
  const res = await fetch(
    `https://dev.to/api/articles?username=${username}&per_page=10`,
    { next: { revalidate: 1800 } } // Next.js cache: 30min
  );
  if (!res.ok) return [];

  const posts: DevToApiPost[] = await res.json();
  return posts.map((p): DevToPost => ({
    id:    p.id,
    title: p.title,
    url:   p.url,
    tags:  p.tag_list || [],
    date:  p.published_at,
    // ... rest of mapping
  }));
}

GitHub — Hiding the token
The GitHub API works without a token for public repos, but you hit rate limits fast (60 req/hour unauthenticated vs 5,000 with a token). The trick: never expose the token to the browser. Use a Next.js API route as a server-side proxy:

// src/app/api/github/route.ts — runs on the server, token stays secret
import { NextRequest, NextResponse } from "next/server";

export async function GET(request: NextRequest) {
  const endpoint = request.nextUrl.searchParams.get("endpoint");

  const res = await fetch(`https://api.github.com${endpoint}`, {
    headers: {
      Authorization: `Bearer ${process.env.GITHUB_TOKEN}`, // server-only!
      Accept: "application/vnd.github.v3+json",
    },
  });

  const data = await res.json();
  return NextResponse.json(data);
}

Then the client hook calls /api/github?endpoint=/users/username — it never sees the token.

Filtering and sorting repos

// src/lib/github.ts
export async function getGitHubRepos(username: string): Promise<GitHubRepo[]> {
  const res = await fetch(
    `https://api.github.com/users/${username}/repos?sort=updated&per_page=20`,
    { next: { revalidate: 3600 } }
  );
  const repos: GitHubRepo[] = await res.json();

  return repos
    .filter((r) => !r.name.includes("fork"))          // no forks
    .sort((a, b) => b.stargazers_count - a.stargazers_count) // best first
    .slice(0, 6);                                      // top 6 only
}

🌍 Trilingual Support (PT / EN / ES)

This was something I added because I want to reach developers from different countries and also practice thinking in English and Spanish. The approach was simple: one big translations object and a React context.

// src/data/i18n.ts (simplified)
export const translations = {
  hero: {
    available: {
      pt: "disponível para oportunidades",
      en: "open to opportunities",
      es: "disponible para oportunidades",
    },
    // ...
  },
  // all sections follow the same pattern
} as const;

// src/data/LangContext.tsx
export function LangProvider({ children }: { children: React.ReactNode }) {
  const [lang, setLangState] = useState<Lang>("pt");

  useEffect(() => {
    const saved = localStorage.getItem("lang") as Lang | null;
    if (saved) setLangState(saved);
  }, []);

  const setLang = (l: Lang) => {
    setLangState(l);
    localStorage.setItem("lang", l); // persists across refreshes
  };

  return <LangCtx.Provider value={{ lang, setLang }}>{children}</LangCtx.Provider>;
}

Then in any component:

const { lang } = useLang();
const h = translations.hero;

<p>{h.available[lang]}</p> // renders in current language

The navbar has a dropdown with flag emojis 🇧🇷 🇺🇸 🇪🇸 — switching language re-renders everything instantly.

🤖 The Chat Assistant

!(You can apply chatting with Google AI Studio in the future)!
This was the most fun part to build. The idea came from this post by @aldwin160 — using an AI chat as a creative way for recruiters to learn about you.
Current state: static responses
I integrated Google Gemini but hit the free tier quota limit (limit: 0 error — the key was linked to a project without the free quota). Rather than block the feature entirely, I built a static response engine that covers the most common recruiter questions:

// src/data/staticChat.ts
const STATIC_RESPONSES = [
  {
    keywords: ["stack", "technology", "tecnologia", "tecnología"],
    answer: {
      pt: "Minha stack principal é **Next.js**, **React**, **TypeScript**...",
      en: "My main stack is **Next.js**, **React**, **TypeScript**...",
      es: "Mi stack principal es **Next.js**, **React**, **TypeScript**...",
    },
  },
  // available, projects, experience, contact, learning...
];

export function getStaticReply(input: string, lang: Lang): string {
  const lower = input.toLowerCase();
  for (const item of STATIC_RESPONSES) {
    if (item.keywords.some((kw) => lower.includes(kw))) {
      return item.answer[lang];
    }
  }
  return FALLBACK[lang]; // fallback: "contact me directly!"
}

Gemini AI — ready to activate
The full Gemini integration is built and commented in ChatWidget.tsx. When I get a proper API key it's literally uncommenting one function:

// src/app/api/chat/route.ts — server-side to avoid CORS
export async function POST(request: NextRequest) {
  const { messages, systemPrompt } = await request.json();
  const key = process.env.NEXT_PUBLIC_GEMINI_KEY;

  const res = await fetch(
    `https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=${key}`,
    {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        system_instruction: { parts: [{ text: systemPrompt }] },
        contents: messages,
      }),
    }
  );

  const data = await res.json();
  const text = data.candidates?.[0]?.content?.parts?.[0]?.text ?? "No response.";
  return NextResponse.json({ text });
}

Important: The Gemini call goes through a Next.js API route, not directly from the browser. This avoids CORS errors and keeps the key server-side.

UX detail: the menu system
After every response, the chat shows the 3 quick-question buttons again plus a "↩ Back to main menu" button. This keeps the conversation flowing even for non-technical visitors who might not know what to ask:

// After each reply, showMenu state triggers the suggestion buttons
const send = (text: string) => {
  const reply = getStaticReply(text, lang);
  setMsgs(p => [...p,
    { role: "user",  content: text  },
    { role: "model", content: reply },
  ]);
  setShowMenu(true); // always show menu after response
};

⚡ Animation Presets with Framer Motion

typescript
Instead of writing the same animation object in every component, I extracted presets:

// src/lib/motion.ts
import type { Transition } from "framer-motion";

export const fadeInUp = {
  initial:     { opacity: 0, y: 24 },
  whileInView: { opacity: 1, y: 0  },
  viewport:    { once: true },
  transition:  { duration: 0.5, ease: "easeOut" } as Transition,
};

export const stagger = (i: number) => ({
  initial:     { opacity: 0, y: 20 },
  whileInView: { opacity: 1, y: 0  },
  viewport:    { once: true },
  transition:  { duration: 0.4, delay: i * 0.08, ease: "easeOut" } as Transition,
});

// Float animation for the chat FAB button
export const floatAnimate = {
  y: [0, -8, 0],
  transition: { duration: 3, repeat: Infinity, ease: "easeInOut" } as Transition,
};

💡 Things I Learned (the hard way)

"use client" is not optional for interactive components
Next.js App Router defaults to Server Components. Any component using useState, useEffect, onMouseEnter etc. needs "use client" at the top. I spent an embarrassing amount of time debugging this error:

Error: Event handlers cannot be passed to Client Component props.
Never call external APIs directly from the browser
The Gemini API blocks browser requests with CORS. The GitHub token would be visible in network tab. Always proxy through a Next.js API route.
Type your API responses, don't use any

// ❌ This will bite you later
const posts: any[] = await res.json();

// ✅ This catches bugs immediately
interface DevToApiPost { id: number; title: string; tag_list: string[]; ... }
const posts: DevToApiPost[] = await res.json();

CSS Variables beat Tailwind for theming For dark/light mode with dynamic values, CSS variables are much cleaner than Tailwind's dark: classes:

:root              { --accent: #16a34a; --bg: #f4f4f8; }
[data-theme="dark"]{ --accent: #7fffb2; --bg: #090910; }

Then style={{ color: "var(--accent)" }} works everywhere, no config needed.

The {app mystery folder At one point I ended up with a literal folder named {app in my project because of a bad bash command. Always double-check your shell scripts.

🔗 Final links

🌐 Portfolio: portfoliodevheron.xyz
🐙 GitHub repo: github.com/devheron/portfolioFull
💬 Inspiration: Portfolio with Gemini by @aldwin160