FraiseQL vs Apollo

Apollo is the most popular GraphQL framework. Here’s how FraiseQL differs — and when each is the right choice.

The Fundamental Difference

Apollo requires you to write resolver functions for every field and relationship.

FraiseQL eliminates resolvers entirely by mapping your schema to optimized database views. It runs as a compiled Rust binary with no resolver code needed.

Side-by-Side Comparison

Aspect	FraiseQL	Apollo Server
Architecture	Compiled Rust binary, database-first	Runtime, resolver-based
Resolver code	None	Required for every field
N+1 handling	Eliminated by design	DataLoader (manual setup)
Configuration	TOML	JavaScript/TypeScript
Schema definition	Code (Python, TS, Go…)	SDL or code-first
Performance	Predictable, sub-ms	Depends on resolvers
Subscriptions	Native (WebSocket + NATS)	Requires Apollo Server + PubSub setup
Schema federation	Built-in multi-database	Apollo Federation (separate package)
Learning curve	Lower	Higher
Flexibility	Database-centric	Unlimited

The Resolver Tax

Apollo: Write Resolvers for Everything

// Apollo Server
const resolvers = {
  Query: {
    users: async (_, args, context) => {
      return context.db.query('SELECT * FROM users');
    },
    user: async (_, { id }, context) => {
      return context.db.query('SELECT * FROM users WHERE id = $1', [id]);
    },
  },
  User: {
    posts: async (user, _, context) => {
      // N+1 problem without DataLoader!
      return context.db.query(
        'SELECT * FROM posts WHERE author_id = $1',
        [user.id]
      );
    },
  },
  Post: {
    author: async (post, _, context) => {
      return context.db.query(
        'SELECT * FROM users WHERE id = $1',
        [post.author_id]
      );
    },
    comments: async (post, _, context) => {
      return context.db.query(
        'SELECT * FROM comments WHERE post_id = $1',
        [post.id]
      );
    },
  },
  Comment: {
    author: async (comment, _, context) => {
      return context.db.query(
        'SELECT * FROM users WHERE id = $1',
        [comment.author_id]
      );
    },
  },
};

Lines of resolver code: 40+ Potential N+1 queries: 4 DataLoaders needed: 3+

FraiseQL: Define Schema Only

Python

# FraiseQL
@fraiseql.type
class User:
    id: str
    name: str
    posts: list['Post']

@fraiseql.type
class Post:
    id: str
    title: str
    author: User
    comments: list['Comment']

@fraiseql.type
class Comment:
    id: str
    content: str
    author: User

TypeScript

import { type } from 'fraiseql';

@type()
class User {
    id!: string;
    name!: string;
    posts!: Post[];
}

@type()
class Post {
    id!: string;
    title!: string;
    author!: User;
    comments!: Comment[];
}

@type()
class Comment {
    id!: string;
    content!: string;
    author!: User;
}

Go

import "github.com/fraiseql/fraiseql-go"

type User struct {
    ID    fraiseql.ID `fraiseql:"id"`
    Name  string      `fraiseql:"name"`
    Posts []Post      `fraiseql:"posts"`
}

type Post struct {
    ID       fraiseql.ID `fraiseql:"id"`
    Title    string      `fraiseql:"title"`
    Author   User        `fraiseql:"author"`
    Comments []Comment   `fraiseql:"comments"`
}

type Comment struct {
    ID      fraiseql.ID `fraiseql:"id"`
    Content string      `fraiseql:"content"`
    Author  User        `fraiseql:"author"`
}

Lines of code: 15 (Python) / 24 (TypeScript) / 21 (Go) Potential N+1 queries: 0 DataLoaders needed: 0

N+1 Problem

Apollo: Manual Prevention

// You must manually implement DataLoaders
const userLoader = new DataLoader(async (ids) => {
  const users = await db.query(
    'SELECT * FROM users WHERE id = ANY($1)',
    [ids]
  );
  return ids.map(id => users.find(u => u.id === id));
});

// And wire them up in context
const context = {
  loaders: {
    user: userLoader,
    post: postLoader,
    comment: commentLoader,
  }
};

// And use them in every resolver
User: {
  posts: (user, _, { loaders }) => loaders.post.loadMany(user.postIds)
}

FraiseQL: Eliminated by Design

-- Composed views: tb_ tables, v_ views, child .data embedded in parent
CREATE VIEW v_comment AS
SELECT c.id, c.fk_post,
    jsonb_build_object('id', c.id, 'content', c.content) AS data
FROM tb_comment c;

CREATE VIEW v_post AS
SELECT p.id, p.fk_user,
    jsonb_build_object(
        'id', p.id, 'title', p.title,
        'comments', COALESCE(jsonb_agg(vc.data), '[]'::jsonb)
    ) AS data
FROM tb_post p
LEFT JOIN v_comment vc ON vc.fk_post = p.id
GROUP BY p.id, p.fk_user;

CREATE VIEW v_user AS
SELECT u.id,
    jsonb_build_object(
        'id', u.id, 'name', u.name,
        'posts', COALESCE(jsonb_agg(vp.data), '[]'::jsonb)
    ) AS data
FROM tb_user u
LEFT JOIN v_post vp ON vp.fk_user = u.id
GROUP BY u.id;

One query. Zero N+1. No DataLoaders.

Schema Definition

Apollo: SDL + Resolvers

schema.graphql

type User {
  id: ID!
  name: String!
  email: String!
  posts: [Post!]!
}

type Post {
  id: ID!
  title: String!
  author: User!
}

type Query {
  users: [User!]!
  user(id: ID!): User
}

Plus all the resolver code shown above.

FraiseQL: Just Types

@fraiseql.type
class User:
    id: str
    name: str
    email: str
    posts: list['Post']

@fraiseql.type
class Post:
    id: str
    title: str
    author: User

Queries and mutations are derived from your SQL views and functions.

Subscriptions

Apollo: Manual PubSub Setup

// Apollo Server subscriptions require a PubSub implementation
import { PubSub } from 'graphql-subscriptions';
const pubsub = new PubSub();

const resolvers = {
  Subscription: {
    userCreated: {
      subscribe: () => pubsub.asyncIterator(['USER_CREATED']),
    },
  },
  Mutation: {
    createUser: async (_, { input }) => {
      const user = await db.createUser(input);
      // Must manually publish to subscribers
      pubsub.publish('USER_CREATED', { userCreated: user });
      return user;
    },
  },
};

For production, graphql-subscriptions must be replaced with a scalable PubSub backend (Redis, MQTT, etc.) and managed separately.

FraiseQL: Native Subscriptions

@fraiseql.subscription(entity_type="User", topic="user_created")
def user_created() -> User:
    """Subscribe to new users via NATS."""
    pass

FraiseQL subscriptions are backed by NATS messaging. When a PostgreSQL function (fn_*) completes a write, FraiseQL automatically publishes the event — no manual pubsub.publish() calls needed.

Federation

Apollo Federation: Composing Multiple GraphQL Services

Apollo Federation is designed to compose multiple independent GraphQL subgraph services into a unified supergraph. Each subgraph is a separate process with its own schema, and the Apollo Router stitches them together at the gateway layer.

users-subgraph/schema.graphql

type User @key(fields: "id") {
  id: ID!
  name: String!
}

# posts-subgraph/schema.graphql
type Post {
  id: ID!
  title: String!
  author: User @provides(fields: "name")
}

extend type User @key(fields: "id") {
  id: ID! @external
  posts: [Post!]!
}

Each subgraph is a separate deployed service. You run an Apollo Router instance in front of them. Federation resolves cross-service references at the gateway level with additional network hops.

FraiseQL Federation: Connecting Multiple Databases in One Process

FraiseQL federation connects multiple databases (PostgreSQL, MySQL, SQLite, SQL Server) inside a single compiled Rust binary. There is no gateway layer, no inter-service network calls, and no subgraph protocol.

fraiseql.toml

[[databases]]
name = "users_db"
url = "${USERS_DB_URL}"

[[databases]]
name = "analytics_db"
url = "${ANALYTICS_DB_URL}"

@fraiseql.type
class User:
    id: str
    name: str
    # analytics field resolved from analytics_db at SQL level
    page_views: int

FraiseQL joins across databases at the SQL view layer — the result is a single query executed by the Rust binary, with no inter-process communication.

Key Difference

	Apollo Federation	FraiseQL Federation
Unit of federation	GraphQL subgraph services	Databases
Architecture	Distributed (multiple processes + gateway)	Single process
Cross-unit join	Network hop through Router	SQL JOIN in view
Deployment	Router + N subgraph services	Single Rust binary
Use case	Independent teams, polyglot services	Multiple databases, monolithic backend

Use Apollo Federation when you need to compose independently deployed services owned by separate teams. Use FraiseQL federation when your data lives in multiple databases but you want a single cohesive backend.

Input Validation

Apollo: Runtime + Decorators

Apollo relies on decorators and custom validation logic:

// Apollo Server with @apollo/server and custom validators
import { GraphQLInputObjectType } from 'graphql';

const userInputValidator = new GraphQLInputObjectType({
  name: 'UserInput',
  fields: {
    email: {
      type: GraphQLString,
      validate: (value) => {
        if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(value)) {
          throw new Error('Invalid email');
        }
      }
    }
  }
});

• Runtime validation — Happens during query execution
• Decorator-based — Use @constraint directives
• Limited scope — Basic rules only (~5-8 validators)
• Manual implementation — Custom validators for complex logic
• Database risk — Invalid data can reach the database

FraiseQL: Compile-Time + Integrated

FraiseQL enforces validation during schema compilation:

[fraiseql.validation]
email = { pattern = "^[^@]+@[^@]+\\.[^@]+$" }
age = { range = { min = 0, max = 150 } }
status = { enum = ["active", "inactive"] }

• 13 built-in validators across 4 categories
  • Standard: required, pattern, length, range, enum, checksum
  • Cross-field: comparison operators, conditionals
  • Mutual exclusivity: OneOf, AnyOf, ConditionalRequired, RequiredIfAbsent
• Compile-time enforcement — Invalid schemas impossible at runtime
• Zero overhead — No per-request validation overhead
• Database protection — Invalid data never reaches the database

Comparison

Aspect	FraiseQL	Apollo Server
Built-in validators	13 rules	~5-8 (via decorators)
Compile-time enforcement	✅ Yes	❌ No
Runtime validation overhead	None	Per-request
Mutual exclusivity	OneOf, AnyOf, ConditionalRequired, RequiredIfAbsent	@oneOf only (via GraphQL spec)
Cross-field validation	✅ Yes	❌ Custom code required
Learning curve	Low	High

Note

Performance comparisons in this page reflect architectural differences — FraiseQL executes pre-built SQL views while Apollo resolvers generate queries at runtime. Actual numbers depend on hardware, database size, query complexity, and resolver implementation. See Performance Benchmarks for controlled benchmark results.

When to Use Apollo

Apollo is a better choice when:

• You need maximum flexibility — Custom data sources, REST APIs, microservices
• Your data doesn’t come from a database — Third-party APIs, computed fields
• You want the ecosystem — Apollo Client, Apollo Studio, Apollo Router
• You need GraphQL Federation at scale — Apollo Federation is mature
• Your team knows the resolver pattern — Familiar mental model

When to Use FraiseQL

FraiseQL is a better choice when:

• Your data is in a database — PostgreSQL, MySQL, SQLite, SQL Server
• You want zero resolver code — Define types, get API
• You need guaranteed performance — No N+1, ever
• You prefer less code — 15 lines vs 40+ lines
• You want simple deployment — Single Rust binary vs Node.js + DataLoaders

Quick Test: Apollo vs FraiseQL

1. Create a simple Apollo Server:

   npm init -y
   npm install apollo-server graphql

   Create index.js:

   const { ApolloServer, gql } = require('apollo-server');
   
   const typeDefs = gql`
     type User {
       id: ID!
       name: String!
       posts: [Post!]!
     }
     type Post {
       id: ID!
       title: String!
       author: User!
     }
     type Query {
       users: [User!]!
     }
   `;
   
   const resolvers = {
     Query: {
       users: () => [{ id: "1", name: "Alice", posts: [] }]
     },
     User: {
       posts: (user) => [{ id: "p1", title: "Hello", author: user }]
     },
     Post: {
       author: (post) => ({ id: "1", name: "Alice", posts: [] })
     }
   };
   
   const server = new ApolloServer({ typeDefs, resolvers });
   server.listen().then(({ url }) => {
     console.log(`Server ready at ${url}`);
   });

2. Test the Apollo API:

   node index.js &
   
   curl -X POST http://localhost:4000 \
     -H "Content-Type: application/json" \
     -d '{"query": "{ users { name posts { title } } }"}'

   Works, but requires 30+ lines of resolver code for simple types.

3. Now try the same with FraiseQL:

   # schema.py - just 10 lines
   import fraiseql
   
   @fraiseql.type
   class User:
       id: str
       name: str
       posts: list['Post']
   
   @fraiseql.type
   class Post:
       id: str
       title: str
       author: User

   fraiseql run
   
   curl -X POST http://localhost:8080/graphql \
     -H "Content-Type: application/json" \
     -d '{"query": "{ users { name posts { title } } }"}'

   Same result, zero resolver code, automatic database integration.

4. Verify N+1 handling:

   In Apollo, you’d need DataLoader to avoid N+1:

   // Apollo requires manual DataLoader setup
   const DataLoader = require('dataloader');
   const userLoader = new DataLoader(async (ids) => {
     // Batch load users
   });

   In FraiseQL, N+1 is impossible by design — the SQL view already JOINs the data.

Migration from Apollo

Step 1: Identify Your Types

Extract types from your SDL:

type User {
  id: ID!
  name: String!
  posts: [Post!]!
}

Step 2: Convert to FraiseQL

Python

@fraiseql.type
class User:
    id: str
    name: str
    posts: list['Post']

TypeScript

import { type } from 'fraiseql';

@type()
class User {
    id!: string;
    name!: string;
    posts!: Post[];
}

Go

import "github.com/fraiseql/fraiseql-go"

type User struct {
    ID    fraiseql.ID `fraiseql:"id"`
    Name  string      `fraiseql:"name"`
    Posts []Post      `fraiseql:"posts"`
}

Step 3: Move Custom Logic to Observers

Apollo resolver:

Mutation: {
  createUser: async (_, { input }, context) => {
    const user = await context.db.insert('users', input);
    await sendWelcomeEmail(user);
    return user;
  }
}

FraiseQL observer (the framework handles CRUD, you react to events):

@observer(
    entity="User",
    event="INSERT",
    actions=[
        email(
            to="{email}",
            subject="Welcome to our platform!",
            body="Hi {name}, thanks for signing up.",
        ),
    ],
)
def on_user_created():
    """Send welcome email when user is created."""
    pass

Step 4: Remove DataLoaders

They’re not needed. Delete them.

Migrating from Apollo? See the step-by-step migration guide.

Summary

Choose	When
Apollo	Maximum flexibility, non-database sources, existing expertise
FraiseQL	Database-first, zero resolvers, guaranteed performance

Apollo gives you more control. FraiseQL gives you less code.

---

Next Steps

Build Your First API

Get a working GraphQL API in minutes. Quick Start Guide

Performance Benchmarks

See how FraiseQL performs compared to Apollo with real numbers. View Benchmarks

Migrate from Apollo

Step-by-step guide to moving your existing Apollo API. Migration Guide

How FraiseQL Works

Understand the compiled, database-first architecture. Core Concepts