TL;DR: After years of wrestling with recursive CTEs, junction tables, and the existential dread of N+1 queries, I built a graph-native Backend-as-a-Service called FLXBL. To prove it actually works (and isn’t just vaporware from a sleep-deprived developer), I built a mock movie discovery platform that finds the shortest path between any two actors. Here’s what I learned—and why you might want to ditch your relational database for relationship-heavy applications.

---

The Problem That Started It All

Have you ever played the Six Degrees of Kevin Bacon game? The premise is beautifully simple: any actor in Hollywood can be connected to Kevin Bacon through their film appearances in six steps or fewer. Tom Hanks was in Apollo 13 with Kevin Bacon—that’s one degree. Meryl Streep was in The River Wild with Kevin Bacon—also one degree.

Simple game. Not-so-simple data problem.

The SQL Nightmare

Here’s what I realized when I first tried to build this: finding a path between two actors requires either recursive queries or graph traversal—and relational databases are notoriously bad at the former while not supporting the latter at all.

Let me illustrate with some SQL that will give you nightmares:

WITH RECURSIVE actor_path AS (
-- Base case: start from Actor A
SELECT
p.id as actor_id,
m.id as movie_id,
ARRAY[p.id] as path,
1 as depth
FROM persons p
JOIN acted_in ai ON p.id = ai.person_id
JOIN movies m ON ai.movie_id = m.id
WHERE p.id = $start_actor_id

UNION ALL

-- Recursive case: find co-stars (and pray for your database's soul)
SELECT
p2.id,
m2.id,
ap.path || p2.id,
ap.depth + 1
FROM actor_path ap
JOIN acted_in ai1 ON ap.movie_id = ai1.movie_id
JOIN persons p2 ON ai1.person_id = p2.id
JOIN acted_in ai2 ON p2.id = ai2.person_id
JOIN movies m2 ON ai2.movie_id = m2.id
WHERE NOT (p2.id = ANY(ap.path))  -- Cycle detection
AND ap.depth < 6
)
SELECT * FROM actor_path WHERE actor_id = $end_actor_id LIMIT 1;

This query has more joins than a yoga class. And it gets exponentially slower as the search depth increases—each hop multiplies the result set by the average number of co-stars (~50 per actor). By hop 3, you’re looking at 125,000 potential paths. By hop 6? Your DBA is updating their resume.

The Realization

I kept running into this problem across different projects: social networks (friends-of-friends), recommendation engines (users-who-liked-also-liked), organizational hierarchies (who-reports-to-whom), supply chains (component-dependencies). The pattern was always the same: entities connected by relationships, where the relationships matter as much as the entities themselves.

And every time, I found myself:

1. Creating junction tables with foreign keys
2. Writing recursive CTEs that made my eyes bleed
3. Implementing manual cycle detection
4. Watching query times go from milliseconds to "let’s grab coffee"

That’s when I thought: What if the database understood relationships natively?

That’s why I built FLXBL.

---

What is FLXBL?

FLXBL (pronounced "flexible") is a Graph-Native Backend-as-a-Service. You define your schema with entities and relationships using a visual editor, and FLXBL automatically generates production-ready REST and GraphQL APIs.

The magic? Under the hood, your data lives in a graph database where relationships are first-class citizens—not foreign keys bolted onto tables.

The Two-Plane Architecture (AKA "The Clever Bit")

FLXBL uses a two-plane architecture that gives you the best of both worlds:

┌─────────────────────────────────────────────────────────────┐
│                    FLXBL Platform                           │
├──────────────────────────────┬──────────────────────────────┤
│     Control Plane            │      Data Plane              │
│     (PostgreSQL)             │      (Neo4j)                 │
│                              │                              │
│  • Schema definitions        │  • Your actual data          │
│  • User authentication       │  • Relationships as edges    │
│  • API key management        │  • Graph traversal queries   │
│  • Webhook configurations    │  • Blazing fast path-finding │
│  • Migration tracking        │                              │
└──────────────────────────────┴──────────────────────────────┘

PostgreSQL handles all the "boring but important" stuff—users, permissions, schemas, API keys. Neo4j handles your actual application data, storing it as a graph where relationships have equal standing with entities.

Why does this matter? Because when you query "find all actors who worked with Tom Hanks," you’re not performing JOINs across junction tables—you’re literally traversing edges in a graph. The database was designed for this operation.

How FLXBL Differs from Firebase/Supabase

Feature	Firebase	Supabase	FLXBL
Data Model	Document (NoSQL)	Relational (PostgreSQL)	Graph (Neo4j)
Relationships	Denormalized/manual	Foreign keys + JOINs	First-class edges
Relationship Properties	Stored in documents	Junction tables	Native edge properties
Multi-hop Queries	Manual, N+1 prone	Recursive CTEs (pain)	Native traversal
Visual Schema Editor	No	Limited	Drag-and-drop with live preview
Auto-generated APIs	REST only	REST + GraphQL (via PostGraphile)	REST + GraphQL (native parity)
AI Integration	No	No	MCP tools for AI-assisted editors, standalone AI apps

The biggest differentiator: FLXBL treats relationships as first-class citizens. If your application is relationship-heavy, you’re working with the data model instead of fighting against it.

---

The "6 Degrees of Kevin Bacon" Project

To demonstrate what FLXBL can do (and frankly, to have some fun), I built a complete movie discovery platform: 6 Degrees of Kevin Bacon.

The app lets you select any two actors and finds the shortest path between them through their shared filmography. Behind the scenes, it’s running a bi-directional breadth-first search across a graph of ~800 actors and movies—and it finds connections.

Full source code: flxbl-dev/6-degrees-of-bacon

---

Modeling the Schema: Thinking in Graphs

When you use FLXBL, you think in terms of entities (the nodes) and relationships (the edges connecting them). Coming from a relational mindset, this is both liberating and slightly disorienting—like learning to ride a bike but the bike is made of concepts.

The Entities

I started with six core entities:

Entity	Purpose	Key Fields
Movie	Films in the database	title, releaseYear, posterUrl, tmdbRating
Person	Actors, directors, writers	name, photoUrl, biography
Genre	Categories like Action, Drama	name
User	Platform users	email, username
Review	User ratings and reviews	rating, content
Collection	Movie franchises, curated lists	name, description

The Relationships (Where the Magic Happens)

Here’s where FLXBL diverges from relational thinking. In PostgreSQL, you’d model "Actor appeared in Movie" with a junction table:

CREATE TABLE acted_in (
person_id UUID REFERENCES persons(id),
movie_id UUID REFERENCES movies(id),
character VARCHAR(255),
billing_order INTEGER,
is_lead_role BOOLEAN,
PRIMARY KEY (person_id, movie_id)
);

Three extra columns, a primary key constraint, and you still need JOINs to query it. In FLXBL, it’s a relationship with properties:

Person --[ACTED_IN]--> Movie
└── character: "Forrest Gump"
└── billingOrder: 1
└── isLeadRole: true

The relationship itself carries data. When I query for Tom Hanks’s filmography, I get both the movies AND the characters he played—in a single traversal. No JOINs. No N+1 queries. Just... data.

Here’s the complete relationship model for the project:

Relationship	From → To	Properties	Purpose
ACTED_IN	Person → Movie	character, billingOrder, isLeadRole	Track who played whom
DIRECTED	Person → Movie	—	Directorial credits
WROTE	Person → Movie	—	Writing credits
HAS_GENRE	Movie → Genre	—	Movie categorization
WROTE_REVIEW	User → Review	—	Review authorship
HAS_REVIEW	Movie → Review	—	Reviews for movies
FOLLOWS	User → User	followedAt	Social graph
WATCHLIST	User → Movie	addedAt, priority	User’s watch queue
WATCHED	User → Movie	watchedAt, rewatchCount	Watch history

Notice FOLLOWS? It connects Users to other Users. Try modeling that elegantly in SQL. Go ahead, I’ll wait.

(Spoiler: You’ll end up with a self-referential junction table and a recursive CTE that questions your career choices.)

---

The Code: Graph Queries That Don’t Make You Cry

Let me show you the actual difference with code from the project.

Fetching an Actor’s Movies (GraphQL)

With FLXBL’s auto-generated GraphQL API, I can fetch an actor’s movies and their character names in one query:

query GetPersonMovies($personId: ID!) {
person(id: $personId) {
name
photoUrl
moviesConnection {
edges {
character        # ← Relationship property!
billingOrder
isLeadRole
node {
id
title
releaseYear
posterUrl
}
}
}
}
}

The moviesConnection returns edges with both the relationship properties (character, billingOrder) and the connected movie nodes. One request. Complete data. Zero existential dread.

The Query DSL: SQL for Graph People

FLXBL also provides a powerful Query DSL for REST that translates to optimized Cypher queries. Here’s a real query from the project:

query GetActorFilmography($name: String!) {
people(where: { name: { equals: $name } }, limit: 1) {
id
name
photoUrl
bio
birthPlace

# Traverse ACTED_IN relationship with edge properties
moviesConnection {
edges {
# Relationship properties
character
billingOrder
isLeadRole

# Target movie with nested genre traversal
node {
id
title
releaseYear
averageRating
boxOffice
posterUrl

# Another traversal: Movie → Genres
genres {
name
iconEmoji
}
}
}
}
}
}

This query says: "In a single request, fetch an actor’s complete filmography with the characters they played, whether it was a lead role, and each movie’s genres - traversing 3 levels of the graph."

In SQL, this would be... let’s just say "significantly more verbose."

The Path-Finding Algorithm: Bi-Directional BFS

The signature feature—finding connections between actors—uses bi-directional breadth-first search. Instead of searching from Actor A all the way to Actor B (which explodes exponentially), I search from both ends and meet in the middle:

Tom Hanks ──────────────> <────────────── Meryl Streep
Forward BFS        Backward BFS
↓
Meeting Point! 🎉

This reduces complexity from O(b^d) to O(2 × b^(d/2)), where b is the branching factor (~50 co-stars per person) and d is the degrees of separation.

Translation for non-algorithm nerds: Instead of checking millions of paths, we check thousands. Your users get results in seconds instead of never.

Here’s a simplified version of the algorithm:

export async function findConnectionPath(
startPersonId: string,
endPersonId: string,
maxDepth: number = 6
): Promise<ConnectionResult | null> {
// Initialize two frontiers - one from each actor
const forwardVisited = new Map<string, BFSNode>();
const backwardVisited = new Map<string, BFSNode>();

let forwardQueue = [startPersonId];
let backwardQueue = [endPersonId];

while (totalDepth < maxDepth) {
// Expand the smaller frontier (more efficient)
const expandForward = forwardQueue.length <= backwardQueue.length;

if (expandForward) {
// Get co-stars via FLXBL's relationship endpoint
const result = await expandFrontier(
forwardQueue,
forwardVisited,
backwardVisited  // Check if frontiers have met!
);

if (result) {
// 🎉 Frontiers met - reconstruct path
return reconstructBidirectionalPath(result.meetingPersonId, ...);
}
}
// ... expand backward frontier similarly
}

return { found: false, degrees: -1, path: [] };
}

The getCoStarsOptimized function uses a hybrid approach—GraphQL for fetching movies (gets relationship properties in one call), and parallelized REST calls for fetching movie casts:

export async function getCoStarsOptimized(personId: string): Promise<CostarWithMovie[]> {
// GraphQL: Get all movies this person acted in (with their characters)
const movies = await getPersonMoviesGraphQL(personId);

// REST: Fetch cast for each movie in parallel (FLXBL handles the load)
const castResults = await Promise.all(
movies.map(async (movie) => ({
movie,
cast: await getMovieCast(movie.id),
}))
);

// Combine into co-star list with movie context
// No N+1 queries because FLXBL batches relationship traversals
return results;
}

---

The Developer Experience: From Zero to API

Let me walk you through what it actually feels like to use FLXBL.

Step 1: Design Your Schema Visually

No YAML files. No migration scripts. Just drag, drop, and connect, fill in the names, the types, the descriptions (if you want to be nice to people that are going to implement what you’re doodling).

Step 2: Get Your APIs Instantly

The moment you publish your schema, FLXBL generates:

REST Endpoints (for every entity):

GET    /api/v1/dynamic/Person           # List all
POST   /api/v1/dynamic/Person           # Create
GET    /api/v1/dynamic/Person/:id       # Get one
PUT    /api/v1/dynamic/Person/:id       # Update
DELETE /api/v1/dynamic/Person/:id       # Delete
POST   /api/v1/dynamic/Person/query     # Query DSL

Relationship Endpoints:

POST   /api/v1/dynamic/Person/:id/relationships/ACTED_IN
GET    /api/v1/dynamic/Person/:id/relationships/ACTED_IN?direction=out
DELETE /api/v1/dynamic/Person/:id/relationships/ACTED_IN/:targetId

GraphQL Endpoint:

POST   /api/v1/dynamic-gql/{tenantId}
GET    /api/v1/dynamic-gql/{tenantId}/schema.graphql  # Download SDL

Step 3: Generate Type-Safe Clients

Use the MCP tools (more on this below) or the API to generate TypeScript interfaces, Zod schemas, or Python Pydantic models:

// Auto-generated from your FLXBL schema
interface Person {
id: string;
name: string;
photoUrl?: string;
biography?: string;
createdAt: string;
updatedAt: string;
}

interface ActedInRelationship {
character?: string;
billingOrder?: number;
isLeadRole?: boolean;
}

No more any types. No more runtime surprises. Just... actual type safety.

---

MCP Integration: AI-Assisted Backend Development

Here’s something that made even me double-take: FLXBL has native integration with Model Context Protocol (MCP), which means AI assistants in Cursor, Windsurf, or VS Code can directly interact with your FLXBL schema.

What Can the AI Actually Do?

Tool	What It Does
validate_schema	Check your schema for errors before publishing
publish_schema_version	Create a new schema version from natural language
check_migration_status	Track migration progress
generate_client_types	Generate TypeScript, Zod, Python, or API contracts
list_schema_templates	Browse pre-built templates for common use cases

Real Example Workflow

Here’s an actual conversation I had with Claude in Cursor:

Me: "Add a Reviews entity to my Movie schema. Users should be able to rate movies 1-5 and leave comments."

Claude: reads current schema via flxbl://schema/active

Claude: "I’ll add a Review entity with rating (NUMBER, 1-5), content (TEXT), and create relationships: WROTE_REVIEW (User → Review) and HAS_REVIEW (Movie → Review). Should I include a timestamp for when the review was written?"

Me: "Yes, add createdAt as a DATETIME."

Claude: uses publish_schema_version tool

Claude: "Done! Schema version 1.3.0 published. The migration is in progress—I’ll check the status."

uses check_migration_status

Claude: "Migration complete. Your new endpoints are ready:

• POST /api/v1/dynamic/Review
• GET /api/v1/dynamic/Movie/:id/relationships/HAS_REVIEW
• ..."

No context switching. No documentation diving. Just... chill. (And production-ready APIs.)

IDE Configuration

{
"mcpServers": {
"flxbl": {
"command": "npx",
"args": ["@flxbl-dev/mcp"],
"env": {
"FLXBL_INSTANCE_URL": "https://api.flxbl.dev",
"FLXBL_API_KEY": "flxbl_your_key_here"
}
}
}
}

---

Security: Because Your Data Matters

A few things I baked in from day one:

Multi-Tenant Isolation

Every query includes automatic tenant filtering. Your data is your data—there’s no universe where a misconfigured query leaks data between tenants.

API Key Security

flxbl_<8-char-prefix>_<48-char-secret>

• Prefix for fast lookup without exposing the secret
• 192 bits of entropy
• Bcrypt-hashed in storage
• Never logged, never exposed

Webhook Verification

All webhooks include HMAC-SHA256 signatures so you can verify they actually came from FLXBL:

const crypto = require('crypto');

function verifyWebhookSignature(payload, signature, secret) {
const hmac = crypto.createHmac('sha256', secret);
hmac.update(JSON.stringify(payload));
return signature === hmac.digest('hex');
}

---

Try It Yourself

The complete "6 Degrees of Kevin Bacon" project is open source and ready to clone:

• Live Demo: 6-degrees-of-bacon.vercel.app
• GitHub: flxbl-dev/6-degrees-of-bacon
• FLXBL Platform: platform.flxbl.dev
• Documentation: flxbl.dev/docs

The repo includes a TMDB seeding script that populates your FLXBL instance with ~50 movies and ~200 actors centered around Kevin Bacon—enough data to demonstrate meaningful path-finding and have some fun discovering unexpected connections.

---

When Should You Use FLXBL?

FLXBL is ideal for:

• Social applications — followers, friends, activity feeds
• E-commerce — product relationships, "frequently bought together"
• Content platforms — authors, posts, comments, tags
• Knowledge graphs — interconnected concepts, research papers
• Organizational tools — reporting hierarchies, team dependencies
• Recommendation engines — user-item-feature relationships
• Anything with "six degrees" problems — and there are more than you think

FLXBL might be overkill for:

• Simple CRUD apps with no relationships
• Document-centric applications
• Time-series data
• Applications that need raw SQL access

---

What’s Next?

FLXBL is in public beta, and I’m actively building based on developer feedback. Some things on the roadmap:

• More schema templates — CRM, CMS, project management out of the box
• Enhanced webhook integrations — Zapier, Slack, and more
• Query DSL improvements — aggregations, nested traversals
• Real-time subscriptions — GraphQL subscriptions for live updates
• Self-hosted option — for those who need it on-prem

If you’re building something relationship-heavy and tired of fighting your database, give FLXBL a try. I’d genuinely love to hear what you build—and what pain points you hit. That’s how this thing gets better.

---

The Bottom Line

Every time I see a recursive CTE or a five-table JOIN for a simple "friends of friends" query, a small part of me dies. Relational databases are incredible tools—but they’re not the right tool for every job.

If your data is fundamentally about connections, relationships, and paths between things, a graph-native approach isn’t just marginally better—it’s a different paradigm. Queries that were "theoretically possible but practically insane" become trivial. Data models that required mental gymnastics become intuitive.

FLXBL is my attempt to bring that paradigm to developers without requiring them to become Neo4j experts, Cypher query authors, or DevOps wizards. Define your schema. Get your API. Build something cool.

What’s the most relationship-heavy application you’ve built? How did you model it? Drop a comment below—I’m genuinely curious about the creative solutions people have found (or the pain they’ve endured).

---

Marko Mijailović is the creator of FLXBL. You can find him on LinkedIn or reach out through email, or join FLXBL Discord