DEV Community: 0xDezman

I Built Mental note: an app That Uses knowledge Graphs to Expose Your Knowledge Gaps

0xDezman — Sun, 05 Jul 2026 22:38:15 +0000

The Problem with Traditional Note-Taking

I am an avid reader—at least, I would love to be identified as that. I love reading books ranging from spiritual topics and personal development to deep dives into technology. But along the way, I was faced with two major problems.

First, for books that explain heavy concepts, I found out I had a massive retention issue. I simply was not able to recollect the deep details inside those pages a few weeks later.

Second, I found it hard to grasp certain complex passages while reading. This made me resort to running Google searches mid-chapter, which constantly interrupted my reading flow.

To fix this, I decided to start taking notes of great points and storing them in my Obsidian vault. That did solve the first part to some extent, as I now had a repository to fall back on every now and then. But I still wasn't retaining the information in my actual memory. It felt like a glorified copy-paste of the book into my personal notes. Even worse, it did nothing to address my second problem of breaking down hard concepts in real-time.

This frustration led me to research better, more scientifically proven ways to learn and retain what you read.

What i Found

During my research process, I came across two powerful frameworks that perfectly articulated what I was experiencing: Schema Theory and the PACER Framework as explained by Dr. Justin Sung.

I came to understand that learning happens in two distinct phases: the consumption phase and the digestion phase. Looking back, my issue wasn't consumption; it was entirely about the digestion phase.

Dr. Sung states that you need different strategies to digest what you learn based on the type of material you are engaging with. The PACER system outlines exact routines for each information type: practice for procedural skills (Practicals), create and critique for comparing alternative approaches (Analogies), mind mapping for core relationships (Concepts), and storing raw data for Evidence. For Reference information—which consists of arbitrary facts like specific dates or precise code syntax—his strategy is to externalize it completely into a dedicated system like flashcards for spaced repetition so it doesn't clutter your working memory.

For me, my problem sat squarely within the A-C-E spectrum: Analogies, Concepts, and Evidence. I thought about manually forcing myself to follow through with these strategies, but I still faced heavily fragmented focus. I would read the e-books on my phone or tackle a hard copy, attempt to map out conceptual relationships using wordy text blocks in my Obsidian notes, and try to critique my understanding using various LLM tabs.

This setup caused a massive loss of focus. I would constantly deviate from reading to doing other random stuff online. Most importantly, I still didn’t have a clear mental picture of how things fit together because I am a highly visual learner—I love visual mappings and Excalidraw diagrams, for example.

So, I realized I had two options:

Build a unified workspace that allows me to study, verify my understanding of analogies and concepts, add supporting evidence, create a beautiful visual map of relationships, and store them directly in markdown notes.
Rely entirely on existing platforms like ChatGPT, Claude, or NotebookLM.

Ultimately, tools like NotebookLM didn't cut it for me. I don't like their rigid graph nodes; I prefer the flexible, visually pleasing layout that an open canvas like Excalidraw offers. Building a custom solution myself gave me the luxury of personalizing the environment and tweaking it to suit my exact cognitive needs.

The Architecture: Cognee Cloud and Excalidraw

Intending to build this solution myself, I immediately faced a classic AI development challenge: the context window bottleneck. Every single time I wanted to query an LLM to check my understanding of a concept, it had to load the entire chapter or book into its memory window. This consumed a massive amount of tokens, meaning more latency and higher expenses.

I needed a permanent, persistent memory setup for my application, and that is where Cognee fit into my pipeline.

Cognee is an open-source data management tool that structures text by extracting semantic triples. Instead of passing massive text files back and forth, it maps information into deterministic structures of [Source] ──[Relationship]──> [Target].

By pairing this graph processing framework on Cognee Cloud as my intelligent backend memory with an embedded Excalidraw Canvas on the frontend, I was able to design a dual-pane workspace. Users can load their e-books or text materials natively on the left pane, chunked down chapter-by-chapter to prevent cognitive overload, while sketching out their visual mental models on the infinite canvas to the right.

Verifying Understanding with Graph Layouts

Using a cloud-persistent graph completely solves my memory issue. It allows me to upload my source material exactly once. Cognee Cloud processes the book text, transforms it into an optimized knowledge graph, and hosts it securely.

This introduces a massive architectural win: it completely decouples the raw book file from the real-time validation loop. Once the graph is serialized into memory, the original heavy PDF or ePub file is irrelevant. The application never has to re-read or re-load the book ever again.

When I finish reading a chapter and draw my mental model on the canvas, I hit a button to verify my layout. The app converts my Excalidraw JSON elements into semantic triples and runs a lightweight graph traversal to mathematically compare my drawn map with the textbook's true graph layout.

If my understanding is flawed, the app calculates the variance and exposes my exact knowledge gaps visually:

If I draw a relationship arrow backward, it flags red.
If a critical connection is missing entirely, a dashed placeholder node appears to show the empty slot in my mental schema.

To guide me through these gaps, an integrated Socratic chatbot panel automatically slides open. Because it reads the exact missing links from the graph engine, it doesn't just blurt out the answer. It acts like a real tutor, asking brief, sharp questions to trigger cognitive accommodation: "Your concept layout for Account Addresses looks solid, but you are missing the cryptographic trigger between the Public Key and the Address. Look back at section 2—how do we get from one to the other?"

By preserving these verified chapter graphs in the cloud, the long-term vision for Mental Note goes even deeper: Cross-Domain Far Transfer. Because all my books live within the same unified graph ecosystem, the app will eventually be able to track network shapes across entirely different subjects. If I map out a brand-new concept that shares the exact same structural graph topology as a framework I studied weeks ago in a different field, the app can proactively surface that familiar analogy to my consciousness—allowing me to assimilate complex new ideas instantly.

Conclusion

My ultimate takeaway from this project is that note apps should not just be a storage vault. Instead, they should function like an active learning assistant and a Socratic teacher that actively helps you test your mental models.

The app is currently optimized as a zero-friction demo. There are no heavy database bottlenecks or sign-up requirements; your chapter notes and Excalidraw mental graphs are saved directly to local browser storage so you can test the validation loop instantly.

I would love to hear about other people's learning workflows! How do you currently break down complex concepts, and prevent yourself from falling into the passive copy-paste trap?

How to Fix CORS Errors in Your Frontend App Using a Proxy Server

0xDezman — Fri, 27 Mar 2026 23:29:54 +0000

Overview

In this tutorial, you'll learn why HTTP requests or API calls made directly from the browser fail with a "Failed to Fetch" error, and how to fix it using the proxy pattern.

Background

If you've ever tried to make an HTTP request or API calls to an external server directly from a frontend JavaScript app, you've likely seen this error:

It shows up in the browser console, but the request never goes through. It can feel confusing because the same call works fine in Postman or curl.

The root cause is not your code. It is a browser security mechanism called CORS, and understanding it is the first step to fixing it.

Same-Origin Policy

Browsers enforce a rule called the Same-Origin Policy. It restricts web pages from making requests to a different origin than the one that served the page.

Three things define an origin:

Protocol — http or https
Domain — localhost or example.com
Port — 3000, 8080, etc.

If any of these three differ between your frontend and the server you're calling, the browser treats it as a cross-origin request.

For example:

Frontend origin	API origin	Same origin?
`http://localhost:3000`	`http://localhost:3000`	✅ Yes
`http://127.0.0.1:5500`	`https://www.youtube.com`	❌ No

Cross-Origin Resource Sharing (CORS)

CORS is the mechanism that controls whether a cross-origin request is allowed.

When your browser makes a cross-origin request, it first sends a preflight request to ask the server: "Do you allow requests from my origin?" If the server doesn't respond with the right headers — Access-Control-Allow-Origin — The browser blocks the request entirely and throws the "Failed to Fetch" error.

💡 Note: This is a browser restriction, not an API restriction. The same request works from a server, Postman, or curl because those environments don't enforce the Same-Origin Policy.

Prerequisites

To follow along, make sure you have:

A basic understanding of HTML and JavaScript
Node.js v18 or higher installed
VS Code with the Live Server extension installed

Project Structure

We'll be working with a simple YouTube Video Info app — it takes a YouTube URL and attempts to fetch the page directly from the browser. It's a straightforward example that clearly demonstrates the "Failed to Fetch" CORS error.

Clone the broken version of the app:

git clone https://github.com/manueldezman/youtube-info.git
cd youtube-info

The project structure looks like this:

broken-version/
├── index.html    # HTML structure
├── styles.css    # Styling
└── app.js        # Frontend logic — calls YouTube directly

To start the app:

Open the project folder in VS Code.
Click Go Live in the bottom right corner to start the Live Server(as shown below).

Your browser will open automatically at http://127.0.0.1:5500.

How a Direct Browser Call Triggers the CORS Error

Paste any YouTube URL into the input field and click Fetch Info. You'll see the button spin for a moment, and then an error appears.

To understand the error, open DevTools by right-clicking anywhere on the page and selecting Inspect, as shown in the media below.

Your console should look like this:

The Cause of the Error

Your frontend is running at http://127.0.0.1:5500 (Live Server). YouTube is at https://www.youtube.com. These are two completely different origins — different protocols, different domains, different ports. The browser sends a preflight request to YouTube asking if cross-origin requests are allowed. YouTube doesn't return the Access-Control-Allow-Origin header for direct page requests, so the browser blocks the request entirely before it even reaches YouTube.

Open app.js and look at the fetchInfo function:

async function fetchInfo() {
  const url = document.getElementById('video-url').value.trim();

  /* ⚠️ Direct browser-to-YouTube call — triggers CORS error */
  const res  = await fetch(url);
  const html = await res.text();
  ...
}

The fetch(url) call goes directly to https://www.youtube.com from the browser, which triggers the CORS block. The request never reaches YouTube, and the app fails silently.

How to Fix the Error Using a Proxy Server

The fix is to stop calling YouTube directly from the browser and instead route the request through your own backend.

Your frontend is running at http://127.0.0.1:5500. YouTube is at https://www.youtube.com. These are two different origins — that's why CORS blocks the request.

The solution is to introduce a Node.js proxy server that sits between the two. Your frontend calls your own backend at http://localhost:3000/fetch. The Node.js server calls YouTube server-to-server — no browser, no CORS enforcement — fetches the page, extracts the video title and description from the HTML meta tags, and returns clean data back to the frontend.

Here's how to add the proxy to the project.

Step 1 — Create server.js

In the project root, create a new file called server.js:

broken-version/
├── index.html
├── styles.css
├── app.js
└── server.js     ← add this

Step 2 — Add the proxy code

Paste the following into server.js:

const http  = require('http');
const https = require('https');
const url   = require('url');

const PORT = 3000;

function extractTitle(html) {
  var match = html.match(/<title>([^<]*)<\/title>/i);
  return match ? match[1].replace(' - YouTube', '').trim() : null;
}

function extractMeta(html, property) {
  var match = html.match(new RegExp('<meta[^>]*(?:name|property)=["\']' + property + '["\'][^>]*content=["\']([^"\']*)["\']', 'i'));
  if (match) return match[1];
  match = html.match(new RegExp('<meta[^>]*content=["\']([^"\']*)["\'][^>]*(?:name|property)=["\']' + property + '["\']', 'i'));
  return match ? match[1] : null;
}

const server = http.createServer(function(req, res) {

  res.setHeader('Access-Control-Allow-Origin', '*');
  res.setHeader('Access-Control-Allow-Methods', 'GET, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type');

  if (req.method === 'OPTIONS') {
    res.writeHead(200);
    res.end();
    return;
  }

  var parsed   = url.parse(req.url, true);
  var videoUrl = parsed.query.url;

  if (parsed.pathname !== '/fetch') {
    res.writeHead(404, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ error: 'Not found' }));
    return;
  }

  if (!videoUrl) {
    res.writeHead(400, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ error: 'Missing url parameter' }));
    return;
  }

  https.get(videoUrl, { headers: { 'User-Agent': 'Mozilla/5.0 (compatible; proxy/1.0)' } }, function(youtubeRes) {
    var body = '';

    youtubeRes.on('data', function(chunk) { body += chunk; });

    youtubeRes.on('end', function() {
      var title       = extractTitle(body) || extractMeta(body, 'og:title') || 'N/A';
      var description = extractMeta(body, 'og:description') || extractMeta(body, 'description') || 'N/A';

      res.writeHead(200, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify({ title: title, description: description }));
    });

  }).on('error', function(e) {
    res.writeHead(500, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ error: e.message }));
  });

});

server.listen(PORT, function() {
  console.log('Proxy server running at http://localhost:' + PORT);
});

This server runs on port 3000. It receives the YouTube URL from the frontend, fetches the page HTML server-to-server, extracts the title and description from the meta tags, and returns clean JSON back to the frontend.

Step 3 — Update app.js

In app.js, find the direct fetch call:

/* ⚠️ Direct browser-to-YouTube call — triggers CORS error */
const res  = await fetch(url);
const html = await res.text();
const title = html.match(/<title>([^<]*)<\/title>/i);

document.getElementById('title').textContent  = title ? title[1].replace(' - YouTube', '') : 'N/A';
document.getElementById('author').textContent = 'N/A';
output.style.display = 'block';

Replace it with:

/* ✅ Calls the local Node.js proxy — not YouTube directly */
const res  = await fetch('http://localhost:3000/fetch?url=' + encodeURIComponent(url));
const data = await res.json();

document.getElementById('title').textContent  = data.title || 'N/A';
document.getElementById('author').textContent = data.description || 'N/A';
output.style.display = 'block';

These also remove the lines that tried to parse the raw HTML; they are no longer needed since the proxy returns clean JSON.

Step 4 — Start the proxy server

Open a new terminal in the project folder and run:

node server.js

You should see:

Leave this terminal running. Keep Live Server running in VS Code at the same time.

Step 5 — Test it

Go back to your browser at http://127.0.0.1:5500, paste a YouTube URL, and click Fetch Info.

The "Failed to Fetch" error is gone. The request now flows from the browser to your own proxy server at localhost:3000, which fetches YouTube server-to-server and returns the video title and description to the browser.

Summary

In this tutorial, you have learnt why HTTP requests made directly from the browser fail with a "Failed to Fetch" error — and how to fix it using the proxy pattern.

The key takeaway is this: browsers enforce the Same-Origin Policy, which blocks cross-origin requests to servers that don't return the right CORS headers. The proxy pattern solves this by routing your requests through your own backend — no browser restrictions, no exposed secrets.

This pattern works for any external server, YouTube, payment APIs, AI platforms, or anything else your frontend needs to talk to securely.

While this tutorial uses a YouTube URL fetch to demonstrate the error, the same proxy pattern applies when calling any external API — whether it's an AI platform like Gemini or OpenAI, a payment API like Stripe, or any other service that blocks direct browser requests. The only difference is that, with APIs, your proxy also handles authentication by securely storing the API key in environment variables on the server, keeping it out of the browser entirely.

Connect with me on my socials if you have any questions or want to follow along with future tutorials.

Thank you for reading, and I look forward to seeing you next time!

cors #javascript #nodejs #webdev #frontend #proxy #apidevelopment