DEV Community: Jeff Lowery

Size Matters: Squeezing a 17,000-Edge Graph Into a Mobile-Friendly JSON

Jeff Lowery — Fri, 24 Jul 2026 20:24:49 +0000

Part 3: How I optimized, packed, and compressed a massive chess opening graph to load instantly on a cheap phone.

In Part 1, we tackled the transpositions and bridged the gap between orphaned variations. In Part 2, we fought the "Source Wars" to clean, sanitize, and merge ten uncooperative data sources (including a relentlessly manual Wikibooks parser).

We finally had a masterpiece: a mathematically sound, beautifully normalized, 17,000-edge directed graph representing the entire tree of chess openings.

But then, I ran a build.

And my output directory spit out a single, monstrous, 4.2 megabyte JSON file.

For a backend pipeline, 4.2 MB is a rounding error. But for a mobile-friendly frontend application where users expect instant interactive feedback on every chess move, shipping a multi-megabyte JSON file over a spotty mobile network is a cardinal sin. It means layout thrashing, high latency, and a miserable user experience.

I had to put the graph on a strict diet. Here is how we got @chess-openings/eco.json down to a featherweight fraction of its original size—without writing a single line of complex compression code.

Why Chess JSONs are Inherently Bloated

Standard, raw JSON is an incredibly expressive format, but when you represent a massive database of moves and names, it is brutally redundant.

Take a look at two actual entries from our master database. Even though these represent two distinct, specific lines of the French Defense, notice how much text is duplicated:

{
  "rnbqkbnr/2pp1ppp/4p3/1p6/3PP3/8/PP3PPP/RNBQKBNR w KQkq - 0 5": {
    "src": "eco_tsv",
    "eco": "C00",
    "moves": "1. e4 e6 2. d4 a6 3. c4 b5 4. cxb5 axb5",
    "name": "French Defense: St. George Defense, St. George Gambit",
    "aliases": {
      "eco_js": "St. George Defense: St. George Gambit",
      "ct": "St. George Defense, St. Georgs Gambit",
      "chessGraph": "St George's Gambit",
      "icsbot": "St George's Gambit "
    }
  },
  "rnbqkbnr/1ppp1ppp/p3p3/8/2PPP3/8/PP3PPP/RNBQKBNR b KQkq - 0 3": {
    "src": "eco_tsv",
    "eco": "C00",
    "moves": "1. e4 e6 2. d4 a6 3. c4",
    "name": "French Defense: St. George Defense, Three Pawn Attack",
    "aliases": {
      "eco_js": "St. George Defense: New St. George, Three Pawn Attack",
      "ct": "St. George Defense, New St. George",
      "chessGraph": "Three Pawn Attack, St George",
      "icsbot": "Three Pawn Attack, St George "
    }
  }
}

Multiply this by 17,000 positions, and you are wasting megabytes on:

Repeating Key Names: Repeating "src", "eco", "moves", "name", "aliases", "eco_js", "ct", "chessGraph", and "icsbot" 17,000 times eats up hundreds of kilobytes of pure ASCII noise.
Duplicate Substrings: Because every single chess opening starts from the exact same board setup, the first few ranks of the FEN strings (like rnbqkbnr/) are virtually identical across thousands of keys.
Semantic Overlap: Common opening names like "French Defense", "St. George Defense", and "Gambit" appear on dozens of sub-variations.

At first glance, it looks like we need to write a highly complex, custom serialization script to tokenize these strings, map them to integer dictionaries, and "rehydrate" the graph on the client side.

But the best engineering solution is the one you don't have to write.

Step 1: Let Gzip Do the Heavy Lifting (via Streams, Not JS Memory)

Instead of over-engineering a complex custom serialization script in Node.js that would eat up system memory loading and processing 17,000 deep objects, we can let standard UNIX utilities and the web's native transport compression do 100% of the work.

I wrote a dead-simple bash script that concatenates the individual JSON segment files (ecoA.json through ecoE.json plus our custom eco_interpolated.json) on the fly.

It treats the files as raw text streams, strips their outer JSON braces using standard sed pipelines, merges them, and pipes the output stream directly into high-level Gzip:

# Strip blank lines, then first and last lines (the outer { and })
strip() {
  sed '/^[[:space:]]*$/d' "$1" | sed '1d;$d'
}

{
  echo '{'
  last_idx=$((${#FILES[@]} - 1 ))
  for i in "${!FILES[@]}"; do
    strip "${FILES[$i]}"
    if [[ $i -lt$last_idx ]]; then
      echo ','
    fi
  done
  echo '}'
} | gzip -9 > "$OUT"

No custom JavaScript transformation, no intermediate combined file, and only modest streaming overhead.

Because our final output has a perfectly flat, highly consistent structure, it is the absolute dream scenario for Gzip's DEFLATE algorithm (which replaces repeating strings with tiny backreference pointers). The repetitive metadata keys ("src", "eco", "moves") and the matching FEN ranks collapse with staggering efficiency.

Step 2: Keeping the Client Code Dead Simple

By resisting the urge to build a custom compression format, we kept our frontend and API code unbelievably clean.

Because the database remains a standard, flat JSON key-value map, the frontend doesn't need a "rehydration" step, a parsing library, or any complex state management. It simply loads the JSON, and our lookup logic is a blazing-fast, O(1) direct memory access:

class ChessOpeningDatabase {
  constructor(jsonData) {
    this.db = jsonData;
  }

  // Blazing-fast direct lookup
  getMetadata(fenString) {
    return this.db[fenString] || null;
  }
}

No CPU-heavy iteration, no dictionary mapping, and zero initialization delay when the application boots up on a cheap mobile device.

The Payoff: Zero Effort, Massive Savings

By keeping the database flat and letting native server-to-browser compression do its job, we achieved a production-ready payload with absolute minimal friction:

The final payload delivered over the wire to the client's browser is 469 KB—smaller than a single average-sized JPEG image. Yet, it contains a fully functional, mathematically sound, 17,000-edge navigational map of the entire history of chess openings, complete with multiple historical source aliases.

Wrapping Up the Chronicles

This project started with a simple problem: my chess video generator had holes in its openings because our data sources didn't understand transpositions.

By the end of this journey, we:

Built a Directed Acyclic Graph (DAG) to map transpositions and engineered synthetic bridges to repair 3,600 "orphan" positions.
Created a normalization sanitizer to force ten chaotic, historical databases to speak with one voice, culminating in a custom scraper to tame a relentlessly uncooperative Wikibooks.
Delivered the entire system as a 469 KB production payload by leaning into structural repetition and native browser compression.

Software engineering isn't just about making things work. Sometimes, it is about knowing when not to write code. By letting standard web protocols do what they do best, we kept our codebase simple, our payload featherweight, and our user experience flawless.

See It in Action

The compressed graph is not merely a benchmark artifact. It powers Fenster, an opening-research web app that lets you play through moves, follow transpositions, and explore the opening names attached to each resulting position.

The opening graph at work in Fenster: one position, several continuations, and a transposition into another opening family. Click the image for a larger view.

[Explore this position in Fenster]

Fenster is the practical test of the architecture described in this series: the graph must be complete enough to navigate, consistent enough to explain what the user is seeing, and small enough to load without getting in the way.

What began as a collection of conflicting opening records is now a usable research tool—one that can trace how openings branch, converge, transpose, and acquire their names.

Source Wars: The Chaos of Ten Conflicting Databases

Jeff Lowery — Wed, 22 Jul 2026 16:51:04 +0000

Part 2: How I forced ten chaotic, crowdsourced, and uncooperative data sources to speak the same language.

In Part 1, The Transposition Trap, we successfully mapped our chess openings into a Directed Acyclic Graph (DAG) and built 3,600 synthetic bridges to link our orphaned variations. Mathematically, our graph was beautiful.

But content-wise? It was a screaming, chaotic tower of Babel.

To build a truly comprehensive, open-source chess opening database, you can't rely on just one source. You have to aggregate. I pulled data from ten different legendary chess repositories: Lichess, Arasan, ICSBot, ChessTempo, and more.

But when I tried to merge them, I realized that chess players—and the developers who write chess software—have been disagreeing on how to write down names, moves, and codes for decades.

This is the story of how I survived the Source Wars.

The Battleground: Name Fragmentation

You would think that a standardized code system like ECO (Encyclopaedia of Chess Openings) would keep things uniform. It doesn't.

ECO codes (like C89) only cover broad families. The actual names of the variations are left to the whims of whoever is typing them into a database. When merging my ten sources, the same exact position would return completely different strings depending on who wrote the file:

Source A: Ruy Lopez: Marshall Attack, Main Line
Source B: Spanish Game: Marshall Gambit
Source C: Ruy Lopez: Marshall, Modern Variation
Source D: Ruy Lopez, Marshall Blackburne Variation

If I merged these blindly, my UI would cycle through four different names for the exact same board state, giving the user digital whiplash. I needed a single, canonical truth.

To solve this, I wrote a custom sanitizer pipeline that strips out fluff words (like "Game", "System", or "Opening" when they don't add value), standardizes punctuation, and forces a strict hierarchy of [Primary Opening]: [Variation], [Sub-variation].

But that was the easy part. Then, I met the ultimate boss of uncooperative data.

The Ultimate Boss: Wikibooks is Not a Database

Of all ten data sources, Wikibooks was the only one relentlessly hostile to automation. Every other source gave me beautifully structured data: TSV columns, CSV rows, nested JSON trees, or good old PGN.

Wikibooks instead gave me 500 human-edited wiki pages where the URL itself is the data source.

Here is how Wikibooks encodes a chess opening's move history:

[https://en.wikibooks.org/wiki/Chess_Opening_Theory/1._e4/1...e5/2._Nf3/2...Nc6/3._Bb5](https://en.wikibooks.org/wiki/Chess_Opening_Theory/1._e4/1...e5/2._Nf3/2...Nc6/3._Bb5)

White moves use {N}._ {piece}{square}, while Black responses use {N}... {piece}{square}. The URL is the move sequence. The HTML page itself only tells you the opening's name—if you are lucky.

The Regex Pipeline of Doom

Extracting Standard Algebraic Notation (SAN) from these URLs required building a multi-pass regex pipeline just to clean up the formatting:

Strip underscores: Translate 1._e4 into 1. e4.
Drop Black move numbers: Parse 1...e5 and strip the leading numbers to get just e5.
The Castling Trap: Wikibooks editors frequently used zeroes instead of the capital letter 'O' for castling. I had to map 0-0 to O-O on the fly.
URL Artifacts: Scrub out percentage-encoded annotations like %2B (check), %3F (theoretical novelty), and ! (good move).

Wikibooks Editors Are Not Database Engineers

The name you scrape from a wiki heading is whatever a volunteer typed in back in 2008. I found "King's Pawn opening" competing with "King's Pawn Game." I found "Latvian Gambit" fighting "Greco Countergambit."

Worse, many sub-variations completely lacked their parent context. A wiki page heading might say simply "Mengarini Variation", but my database needed the full lineage: "Sicilian Defense: Mengarini Variation".

To keep my sanity, I had to maintain a 4,244-entry alias map (aliases.txt) to manually normalize Wiki names to canonical forms. I also designed a word-overlap algorithm that looks at the parent page, determines if the child heading is missing context, and prepends the parent's opening name—but only if the overlap is insufficient. (For instance, "Latvian Gambit: Mayet Attack" only needs "Mayet Attack" appended, not the full parent string).

Malformed URLs and Dead Ends

When humans write URLs, things break. Eight wiki pages had URLs that completely violated the naming convention. I ran into missing underscores (4.e5 instead of 4._e5), extra periods (4....Nfd7), and a Caro-Kann variation whose URL inexplicably pointed to a London System page. I had to hardcode a corrections.json file to intercept and patch these malformed URLs before the regex engine even looked at them.

I also hit the "anonymous continuation" dead end. Some wiki pages exist solely to sub-divide a long variation, so their heading is just the parent opening's name repeated. The page for:
1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O
...had the heading "Ruy Lopez".

This is identical to the root opening eight moves prior! These are paths the wiki community wanted to document, but never bothered to name. My parser had to detect these by measuring the move-back distance, skipping them entirely rather than polluting the database with duplicate names.

The MediaWiki API as a Change Detector

To avoid hammering Wikipedia's servers, I wrote a change-detection script. The parser queries the MediaWiki API for the last revision timestamp of the Chess_Opening_Theory root page. If nothing has changed, the parser refuses to run.

I took this a step further with a custom tool, diff-wiki.js. It fetches the 500 most recent edits to the category, filters them down to our specific opening pages, deduplicates them, and displays exactly which lines changed. This lets me audit human edits before committing to a full database rebuild.

The Name-Resolution Algorithm

Once the Wikibooks data was scraped, sanitized, and corrected, I merged it back into the master pool with the other nine sources. To resolve conflicts when multiple sources claimed different names for the exact same FEN, I established a strict Source Hierarchy:

const SOURCE_PRIORITY = [
  'lichess',      // Most modern, clean, and player-standardized
  'caissa',       // Solid, historically accurate database
  'wikibooks',    // Rich in variation names, but needs heavy sanitization
  'arasan',       // Great engine book, but terse names
  'openings_txt'  // Legacy fallback
];

When two databases disagreed, the algorithm checked the priority array. If lichess named a position "Sicilian Defense: Old Sicilian", it overrode arasan calling it "KP: Sicilian".

If the conflict was between names within the same priority level, a string similarity threshold (using Jaro-Winkler distance) evaluated the options. If they were 95% similar, it picked the shorter, cleaner name. If they diverged completely, it flagged the FEN for manual review in my corrections.json file.

The Result: One Voice for 17,000 Positions

By building a robust sanitization pipeline, surviving the wild west of Wikibooks URL-scraping, and enforcing a strict source hierarchy, we achieved something incredible.

We took ten fragmented, historical, and crowdsourced files and merged them into a singular, cohesive database. Every single one of our 17,000 graph edges (named openings + interpolated positions now speaks with the exact same voice.

The lesson here is simple: crowdsourced data isn't dirty—it's just data that trusted its authors instead of its consumers. Parsing it means building a solid bridge between human editing habits and machine-readable structures.

Now that our data is clean, unified, and fully connected, we face our final hurdle: How do we fit a 17,000-edge graph into a file small enough to load instantly on a cheap phone?

Watch for Part 3: Size Matters!

The Transposition Trap and 3,600 "Fake" Chess Positions

Jeff Lowery — Tue, 14 Jul 2026 22:08:18 +0000

Part 1: The Graph, The Orphans, and the Synthetic Bridge

If you ask a casual chess player what an opening is, they’ll give you a simple answer: it’s a name, an ECO (Encyclopedia of Chess Openings) code, and a sequence of moves.

1. e4 e5 2. Nf3 Nc6 3. Bb5 is the Ruy Lopez. Clean. Elegant. Linear.

If you ask a software engineer who maintains a chess opening database how hard it could be to map these openings, they’ll likely utter the famous last words of every data engineer:

"It’s just a flat list of moves. How hard could it be?"

I know this because I am that engineer. I maintain @chess-openings/eco.json, an open-source data package on npm. And during a recent extensive rewrite of my data pipeline, I was violently reminded that in the world of chess data, linearity is an illusion, FEN strings are slippery shapes, and the data structure isn’t a list at all.

It’s a directed nightmare of a graph.

The Transposition Trap

Let’s start with the fundamental lie of chess data: that a position’s identity is tied to how you got there.

In chess, different move orders can lead to the exact same layout of pieces on the board. This is known as a transposition. Consider the Benoni Defense. You can reach a classic Benoni position via the canonical move order:

1. d4 Nf6 2. c4 c5 3. d5

But what happens if Black plays a slightly different order to achieve the exact same strategic setup?

1. c4 c5 2. d4 Nf6 3. d5

To the human eye, the board is identical. To a database relying strictly on Forsythe-Edwards Notation (FEN) as a strict unique identifier, they can look like entirely different entities. A standard FEN string doesn't just track where the pieces are; it tracks whose turn it is, castling rights, and potential en passant squares.

If White changes the order of their pawn pushes, castling rights or en passant availability might technically differ for a fleeting move, even if the piece layout converges. (Yes, I hear you, chess purists: technically, an active en passant option makes identical piece layouts mathematically distinct game states. But for the sake of navigation mapping, we must occasionally fly close to the sun).

If your data pipeline treats a full, standard FEN string as an absolute, immutable identity, you will instantly split your data universe in two.

The fix? I had to implement a strict position-only FEN matching fallback across the entire ingestion engine. In chess data engineering, you quickly learn that a full FEN is merely a suggestion; the raw piece placement layout is the true identity.

A Directed Nightmare: The `fromTo` Graph

Once you accept that positions transpose, your flat file of chess openings explodes into a massive directed graph. In my latest build of the pipeline, this graph ballooned to 17,500 edges connecting over 16,000 unique nodes.

[Position A] --(Move: c5)--> [Position B] --(Move: d5)--> [Position C]
    \                                                         /
     \-----------------(Alternative Path)--------------------/

Every single opening and variation in the database must know where it came from (from) and where it can go (to). If a single link breaks, that entire branch of chess history becomes unreachable noise in the application layer.

When I ran my newly rewritten pipeline for the very first time, it didn't gracefully compile. It screamed. The integrity report spat out:

45 disconnected interpolated openings (floating in the void)
87 duplicate edges (circular logic loops)
16 FEN collisions (two different opening names claiming the exact same board state)

Fixing this wasn’t a matter of tweaking a JSON file. It required rewriting four fundamental pipeline changes across three separate architecture files to enforce strict deduplication at the moment of generation, rather than trying to retrofit it after the fact.

The Interpolation Rabbit Hole

But the deepest psychological damage came from what I call "Orphan Openings."

The immediate problem appeared in Fenster, my browser-based opening research app: legitimate opening lines sometimes became unreachable because their source records did not form a continuous path.

When you scrape, merge, and normalize chess-opening data from ten different online sources, you inevitably encounter records for deeply specific subvariations. A source might, for example, name a line twenty moves deep in the King’s Indian Defense.

The problem is that the source may contain a record for an early position, Opening A, and another for a much deeper position, Opening Z, while omitting every intervening position. Opening Z’s move list includes the moves that pass through those positions, but the source provides no separate entries for them.

This leaves a broken path in the opening graph. Opening A has no chain of child positions leading forward to Opening Z, even though Opening Z’s move sequence reveals exactly what those missing positions must be. To connect the graph, the intervening positions must be generated from Opening Z’s move list and inserted between A and Z.

To make the graph navigable, I had to build an interpolation engine. When the pipeline encounters an orphan, it is forced to go down a recursive rabbit hole. It triggers a function called lineOfDescent, which programmatically walks backward through the move sequence, move by move, generating synthetic bridge nodes until it finally collides with a known, recognized opening.

Think about the absurdity of this: I had to programmatically generate 3,625 synthetic chess positions solely so that real chess openings could find each other.

These interpolated entries don't have historical flavor text or specific human names; they exist purely as the digital mortar holding the bricks of the graph together. If the recursion logic is off by even a single character, it triggers a recursion explosion, spinning out infinitely as it tries to resolve transpositions that loop back on themselves.

The Joy of the Green Check

After days of wrestling with the graph topology, adjusting fallback FEN algorithms, and ensuring the lineOfDescent didn't eat my CPU, I finally ran the verification suite.

There is a unique, quiet satisfaction that only a developer knows when a wall of red terminal text finally turns into a clean, green monolithic block of passing checks:

✓ fen-unique: 12509 unique in ecoA-E, 3625 in interpolated, 0 overlaps
✓ eco-prefix: all entries match their category file
✓ interp-isolation: interpolated entries correctly separated
✓ fromto-ref: all 17565 transitions reference existing FENs
✓ fromto-dup: no duplicate transitions
✓ valid-src: all source identifiers are valid
✓ rootsrc: all 3625 interpolated entries have rootSrc
✓ interp-connect: all 3625 interpolated entries connected in fromTo graph

✗ 0 failure(s)

The graph was whole. The orphans were adopted. The synthetic bridges held.

But normalizing the graph topology was only half the battle. Once the architecture was solid, I had to plunge into the messy, politically charged, and deeply inconsistent world of human naming conventions—a data normalization war where there are no winners.

In the next article, we’ll dive into "Source Wars," dealing with the chaos of ten conflicting databases, and why "King's Indian Attack" and "Reti: KIA" are a data engineer's worst nightmare.

How to build an associative graph using React + p5

Jeff Lowery — Sun, 12 May 2024 19:21:23 +0000

The idea

I've been working on a chess opening database in my copious spare time, and have begun experimenting with visualizations of said openings. One of those is a relationship graph (see above) that displays origin square to destination square of each opening move.

The Farmer in the Dell

Relationships (a type of association) can be found everywhere. In this post, I'll graph the relationships as described in a nursery rhyme called "The Farmer in the Dell".

The farmer in the dell
The farmer in the dell
Hi-ho, the derry-o
The farmer in the dell

After establishing that there's a farmer that lives in a dell, a series of new characters are introduced via the verb "takes".

The farmer takes a wife
The wife takes the child
The child takes the nurse
The nurse takes the cow
The cow takes the dog
The dog takes the cat
The cat takes the mouse
The mouse takes the cheese
The cheese stands alone

The word "takes" is way overloaded here, but that can be addressed later. From this list of relationships we can see that the farmer and the cheese have a single relation (terminal nodes in the graph to come), but all other characters have two.

Graphing the characters

To display the relationships among the characters in the rhyme, we can start by arranging each in a circle.

I'm using the JavaScript graphics library p5 inside a react component, like so:

/* eslint-disable react/prop-types */
import { useRef, useEffect } from "react";
import p5 from "p5";

const characters = {
    farmer: {},
    wife: {},
    child: {},
    nurse: {},
    cow: {},
    dog: {},
    cat: {},
    mouse: {},
    cheese: {},
};

const Version1 = () => {
    const renderRef = useRef();

    useEffect(() => {
        let remove;

        new p5((p) => {
            remove = p.remove;
            p.setup = () => {
                const r = 250;
                const cast = Object.entries(characters);

                for (const [index, [key]] of Object.entries(cast)) {
                    const character = characters[key];
                    character.angle =
                        (p.TWO_PI / Object.keys(characters).length) * index;
                    character.location = [
                        r * p.sin(character.angle),
                        r * p.cos(character.angle),
                    ];
                }

                p.createCanvas(600, 600).parent(renderRef.current);
                p.background(150)
                //move 0,0 to the center of the canvas
                p.translate(p.width / 2, p.height / 2);
                p.ellipseMode(p.CENTER);
                p.textAlign(p.CENTER, p.CENTER);
                p.textFont("Georgia");

                for (const c in characters) {
                    const [x, y] = characters[c].location;
                    p.ellipse(x, y, 40);
                    p.text(c, x, y);
                }
            };
        });

        return remove;
    });

    return <div id="Version1" ref={renderRef}></div>;
};

Without delving too deep into p5, it's worth pointing out some features of this code.

How to render graphics inside a React component

const renderRef = useRef();
p.createCanvas(600, 600).parent(renderRef.current);
return <div id="Version1" ref={renderRef}></div>;

useEffect() cleanup function

    useEffect(() => {
        let remove;

        new p5((p) => {
            remove = p.remove;
        /* ... */
        });
        return remove;
   });

the p5 remove function 'cleans up' the previous render before useEffect is called again.

Setting up the character locations

         p.setup = () => {
                const r = 250;
                const cast = Object.entries(characters);

                for (const [index, [key]] of Object.entries(cast)) {

Note the two Object.entries() calls. This is done to get an index to calculate each character's angle from the center:

     character.angle =
        (p.TWO_PI / Object.keys(characters).length) * index;

Drawing the relationships

Now to draw a line from each taker to each taken character. First, I add a "takes" relation from farmer all the way down to cheese, then draw a line from the taker location to the taken location.

const doRelations = () => {
    // for this version, all relations are the same.
    const keys = Object.keys(characters);
    keys.forEach((key, i) => {
        if (i + 1 < keys.length) {
            characters[key].takes = keys[i + 1];
        }
    });
};

/* ... */
for (const c in characters) {
    const character = characters[c];
    const [x, y] = character.location;

    if (character.takes) {
        const taken = characters[character.takes];
        const [x2, y2] = taken.location;
        p.line(x, y, x2, y2);
    }

    p.ellipse(x, y, 40);
    p.text(c, x, y);
}

The result:

Not terribly interesting, but it's a start.

Requirements analysis

Let's reexamine the word "takes". It's usage is very ambiguous and often nonsensical. Here's one attempt to disambiguate the rhyme:

The farmer married a wife
The wife married a farmer
The wife adopts the child
The wife employs the nurse
The child needs the nurse
The nurse cares for the child
The farmer owns the cow
The nurse milks the cow
The farmer owns the dog
The dog guards the cow
The dog befriends the cat
The cat befriends the dog
The cat adopts the farmer
The cat hunts the mouse
The mouse eats the cheese

Let's see what the relationship graph looks like now:

Not bad, but now let's color-code the relationships and add a legend:

Drawing curves instead of lines

One problem with using lines is that in reciprocal relationships, such as "married", one line overwrites another, obscuring the former relationship. Bezier curves can be used instead of lines, and look better. Each bezier curve takes eight arguments, which are the (x,y) coordinates of:

the start point
the first control point
the second control point
the end point

What are these control points? Here's an illustration:

The shape of the curve can be adjusted by moving the control points. In this case, I'll set the first control point to be halfway between the start location and the center of the graph, and similarly for the end point.

    const cp1 = [x / 2, y / 2];
    const cp2 = [x2 / 2, y2 / 2];

    p.noFill();
    p.bezier(x, y, ...cp1, ...cp2, x2, y2);

The result is:

Though aesthetically better, the change didn't fix the overwrite problem. The control points can be adjusted for each character by adding a "fudge" factor to the control point equation:

    const fudge = (v) => ((v*i*3)/40)

    const nx = x + fudge(x)
    const ny = y + fudge(y)
    const nx2 = x2 + fudge(x2)
    const ny2 = y2 + fudge(y2)

    i++;

    const cp1 = [nx / 2, ny / 2];
    const cp2 = [nx2 / 2, ny2 / 2];

Here, the variable i is a counter that is increased as each character in the rhyme is rendered. The final output is:

Arrows? What about arrows?

One thing missing from the diagram is an indication of the direction of the relationship, e.g. "farmer owns dog" and not "dog owns farmer". However, there is no native support for arrowheads in p5, so it takes quite a bit of trigonometry to draw them...another post in itself. See links below for more info on the subject.

References

A complete program can be found here.

Useful links:

This example gets halfway to an arrow feature.

One thing is to have the tip of the arrow touch the edge of each character's circle, using the formula in the answer found here.