Уявіть: ваш API обробляє запит списку статей. Кожна стаття підвантажує автора та коментарі. Без батчингу це перетворюється на (1 запит для списку + N запитів для авторів + M запитів для коментарів). При N=100 і M=50 отримуємо 151 запит замість 3. DataLoader скорочує це до 3 запитів — економія часу в 10 разів. При високому навантаженні економія на інфраструктурі може бути суттєвою. В одному з проєктів з медіа-платформою ми скоротили час відповіді з 4 секунд до 200 мс, застосувавши DataLoader та пагінацію.
Ми стикалися з проєктами, де через наївну реалізацію резолверів час відповіді API падав до 10 секунд. Кожен запит користувача генерував десятки SQL-запитів — проблема N+1 у дії. Авторизація на рівні полів була відсутня, що призводило до витоку даних. Розповідаємо, як це виправити: використовуємо DataLoader, контекстну авторизацію та тести. Наш досвід — понад 5 років, більше 50 проєктів на GraphQL, включно з високонавантаженими системами.
Чому оптимізація N+1 критична?
Проблема N+1 — головний ворог продуктивності GraphQL. Коли резолвер для списку об'єктів викликає для кожного елемента окремий запит до БД, це призводить до експоненційного зростання часу відповіді. DataLoader вирішує проблему, але вимагає правильної інтеграції.
| Техніка | Опис | Продуктивність | Складність |
|---|---|---|---|
| DataLoader | Batching + caching per request | Висока | Середня |
| Batch SQL (IN clause) | Запит з IN або JOIN | Висока | Низька |
| Пагінація + обмеження глибини | Limit глибини запитів | Середня | Низька |
| Наївний підхід | N+1 запитів | Низька | Низька |
| Сценарій | Час відповіді (100 статей) | Кількість запитів |
|---|---|---|
| Наївний | 1500 мс | 151 |
| DataLoader | 150 мс | 3 |
| Batch SQL | 120 мс | 3 |
DataLoader кращий за наївний підхід у 10-50 разів за часом відповіді залежно від глибини вкладеності. Застосування DataLoader у зв'язці з пагінацією дає ще більший ефект на високонавантажених проєктах.
Як DataLoader вирішує проблему N+1?
DataLoader — це утиліта для батчингу та кешування запитів. Він групує множинні звернення до БД в один запит, що значно знижує навантаження. Важливо створювати екземпляр DataLoader на кожен запит, щоб уникнути крос-користувацького кешу. DataLoader is a generic utility to be used as part of your application's data fetching layer to provide a simplified and consistent API over various backends and reduce requests to those backends via batching and caching. Детальніше про DataLoader на сторінці проєкту.
const resolvers = {
Query: {
user: async (parent, { id }, context) => {
if (!context.user) throw new AuthenticationError('Not authenticated');
return context.db.users.findById(id);
},
posts: async (parent, { limit, offset }, context) => {
return context.db.posts.findAll({ limit, offset });
}
},
User: {
posts: async (parent, args, context) => {
return context.loaders.postsByUserId.load(parent.id);
}
},
Post: {
author: async (parent, args, context) => {
return context.loaders.userById.load(parent.id);
},
comments: async (parent, args, context) => {
return context.loaders.commentsByPostId.load(parent.id);
}
}
};
Чому важливо створювати DataLoader на кожен запит?
Використання одного екземпляра DataLoader для всіх користувачів може призвести до витоку даних: кеш одного користувача може бути відданий іншому. Тому ми створюємо новий DataLoader у контексті кожного запиту, гарантуючи ізоляцію.
Контекст та Dependency Injection
Контекст запиту формується на кожному запиті: аутентифікація, створення DataLoader, передача БД.
import { ApolloServer } from '@apollo/server';
import { DataloaderRegistry } from './dataloaders';
const server = new ApolloServer({ typeDefs, resolvers });
app.use('/graphql', expressMiddleware(server, {
context: async ({ req }) => {
const token = req.headers.authorization?.replace('Bearer ', '');
const user = token ? await verifyToken(token) : null;
const loaders = new DataloaderRegistry(db);
return { user, db, loaders, req };
}
}));
Авторизація на рівні полів
Перевірка прав доступу в кожному резолвері через допоміжні функції.
function requireAuth(context) {
if (!context.user) {
throw new GraphQLError('Not authenticated', {
extensions: { code: 'UNAUTHENTICATED' }
});
}
}
function requireRole(context, role) {
requireAuth(context);
if (!context.user.roles.includes(role)) {
throw new GraphQLError('Forbidden', {
extensions: { code: 'FORBIDDEN' }
});
}
}
// Використання в мутації
const resolvers = {
Mutation: {
deletePost: async (parent, { id }, context) => {
requireAuth(context);
const post = await context.db.posts.findById(id);
if (!post) throw new UserInputError('Post not found');
if (post.author_id !== context.user.id && !context.user.roles.includes('admin')) {
throw new GraphQLError('Cannot delete others\' posts', {
extensions: { code: 'FORBIDDEN' }
});
}
await context.db.posts.delete(id);
return { success: true };
}
}
};
Як тестувати резолвери?
Тести захищають від регресій при змінах схеми та бізнес-логіки. Ми покриваємо кожен резолвер unit-тестами, ізолюючи БД та DataLoader за допомогою моків. Додаємо інтеграційні тести для перевірки спільної роботи резолверів.
describe('Post resolvers', () => {
const mockDb = { posts: { findById: jest.fn(), delete: jest.fn() } };
const mockContext = (overrides = {}) => ({
user: { id: '1', roles: ['user'] },
db: mockDb,
loaders: { userById: { load: jest.fn() } },
...overrides
});
it('deletePost: owner can delete', async () => {
mockDb.posts.findById.mockResolvedValue({ id: '1', author_id: '1' });
mockDb.posts.delete.mockResolvedValue(true);
const result = await resolvers.Mutation.deletePost(null, { id: '1' }, mockContext());
expect(result).toEqual({ success: true });
});
it('deletePost: non-owner gets FORBIDDEN', async () => {
mockDb.posts.findById.mockResolvedValue({ id: '1', author_id: '99' });
await expect(
resolvers.Mutation.deletePost(null, { id: '1' }, mockContext())
).rejects.toMatchObject({ extensions: { code: 'FORBIDDEN' } });
});
});
Чому обробка помилок важлива?
Помилки мають бути інформативними, але не розкривати деталі БД у продакшені. Apollo Server дозволяє налаштувати форматування помилок через formatError.
import { GraphQLError } from 'graphql';
import { ApolloServerErrorCode } from '@apollo/server/errors';
const resolvers = {
Mutation: {
createPost: async (parent, { input }, context) => {
requireAuth(context);
if (!input.title?.trim()) {
throw new GraphQLError('Title is required', {
extensions: { code: ApolloServerErrorCode.BAD_USER_INPUT }
});
}
try {
return await context.db.posts.create({ ...input, author_id: context.user.id });
} catch (err) {
console.error('DB error:', err);
throw new GraphQLError('Internal server error', {
extensions: { code: 'INTERNAL_SERVER_ERROR' }
});
}
}
}
};
// Форматування в продакшені
const server = new ApolloServer({
typeDefs, resolvers,
formatError: (formattedError, error) => {
if (process.env.NODE_ENV === 'production' &&
formattedError.extensions?.code === 'INTERNAL_SERVER_ERROR') {
return { message: 'Internal server error' };
}
return formattedError;
}
});
Процес роботи
- Аналіз схеми GraphQL — виявляємо типи, відношення, вузькі місця.
- Проєктування резолверів з урахуванням гранулярності доступу.
- Реалізація з DataLoader, авторизацією та обробкою помилок.
- Покриття тестами (unit + інтеграційні).
- Документування та деплой з CI/CD.
Що входить у роботу
- Вихідний код резолверів з тестами (Jest).
- Документація API (GraphQL SDL + README).
- Налаштування CI/CD (GitHub Actions, Docker).
- Навчання команди роботі з резолверами.
Строки та вартість
Строк розробки — від 2 до 5 робочих днів залежно від складності схеми. Вартість розраховується індивідуально. Отримайте консультацію інженера — ми проаналізуємо вашу схему GraphQL і запропонуємо оптимальне рішення. Замовте аудит ваших резолверів — це займе не більше години. Зв'яжіться з нами для оцінки вашого проєкту.