От идеи до API за вечер: представляю CastAPI — конструктор бэкенда для стартапов и инди-разработчиков
Возьмём типовую задачу: нужно сделать backend для небольшого приложения — например, база заметок с тегами и пользователями. Даже если вы опытный разработчик, вы всё равно потратите:
- 30–60 минут на создание проекта, подключение БД, настройку ORM;
- ещё час на описание моделей и миграций;
- около двух часов на написание CRUD-эндпоинтов с валидацией и авторизацией;
- плюс час на генерацию документации (или ручное описание в Swagger).
Итого — 4–5 часов чистого времени. А если нужно переделать схему данных? Добавить новое поле? Снова писать миграцию, править контроллеры, обновлять документацию. За месяц таких «быстрых» проектов может набежать несколько дней потерянного времени. И это при том, что 80% кода — типовой, одинаковый от проекта к проекту.Лично я в прошлом году запустил три пет-проекта. В каждом — одна и та же боль: кручу один и тот же CRUD, копирую контроллеры из предыдущего репозитория, меняю названия полей… На третий раз мне стало физически тошно. Поэтому я и начал делать CastAPI.
Прежде чем сесть и писать свой велосипед, я честно попытался найти готовый инструмент. Перепробовал несколько вариантов — у каждого оказались свои подводные камни.
🔥 Firebase (Google)
Это первое, что приходит в голову. Настройка за 5 минут, SDK под любую платформу, реальное время… Но:
- Vendor lock-in. Через год вы понимаете, что ваши данные заперты в их NoSQL-модели. Вытащить их в нормальную PostgreSQL без боли — квест с 3–4 днями правок.
- Сложная бизнес-логика. Всё, что сложнее простых правил безопасности, приходится писать на Cloud Functions (Node.js). Получается тот же код, но в их окружении.
- Цена. При первом же серьёзном трафике счёт может улететь в космос. Был случай: пет-проект с 5k пользователей выкатил счёт на $200 за месяц — только за чтение/запись.
Вердикт: для прототипа — ок, но для продукта, который не хочется переписывать через год, — нет.
🐘 Supabase
Отличная попытка сделать open-source альтернативу Firebase на PostgreSQL. Но и у неё есть нюансы:
- Авторизация и RLS (Row Level Security). Всё завязано на политики внутри БД. Пока разберёшься, как правильно написать RLS для сложных ролей, уже час пролетел.
- Кастомная бизнес-логика. Есть Edge Functions (аналог Cloud Functions), но они пока сыроваты и медленнее, чем хотелось бы.
- Миграции. Supabase накатывает свои миграции поверх вашей схемы. При попытке выехать из их экосистемы (например, поднять свою БД) получаете хаос из системных таблиц и триггеров.
Вердикт: честная попытка, но для сложной логики всё равно приходится писать код и разбираться в их внутренностях.
⚙ Amplication
Генерирует готовый backend на NestJS + Prisma. Звучит круто: скачал код — запустил. Но:
- Сгенерированный код — это ваш код. Его нужно поддерживать, обновлять, деплоить, чинить конфликты версий библиотек.
- При перегенерации модели (добавил поле) — вы теряете свои ручные правки в контроллерах. Приходится либо не трогать модель, либо писать обёртки.
- Документация не обновляется автоматически при изменении схемы (точнее, обновляется, но только если вы не трогали Swagger руками).
Вердикт: хорош для одноразового прототипа, но не для живого проекта, где модель меняется каждую неделю.
📦 Самописный генератор кода
Думал: «Напишу свой скрипт, который по JSON-схеме генерирует модели, миграции и контроллеры». Потратил на это выходные. Получилось… и тут же появились проблемы:
- Генератор нужно поддерживать. Добавил новое поле типа jsonb — надо править генератор.
- Ошибки в сгенерированном коде — их сложно отлаживать, потому что вы смотрите не на свой код, а на результат генерации.
- Документацию всё равно надо генерировать отдельно. И синхронизировать с изменениями схемы.
Вердикт: вместо экономии времени получил второй проект на поддержку.
📱 Привязка к SDK — отдельная боль
Почти все перечисленные решения (Firebase, Supabase, Amplication) заставляют вас использовать их SDK на клиенте. Это удобно, пока вы пишете под одну платформу. Но как только понадобится:
- написать Telegram-бота на Python,
- сделать интеграцию с микросервисом на Go,
- отправить запрос из чистого cURL или из скрипта на Bash,
- или подключить realtime‑функционал через WebSocket с кастомным клиентом,
— вы начинаете танцевать с бубном: эмулировать SDK, разбираться в их внутреннем протоколе, писать обёртки. Универсальные протоколы вроде чистого REST API и WebSocket (RFC 6455) уходят на второй план, а без них вы плотно привязаны к экосистеме конкретного вендора.
🧠 Что в итоге?
Я понял, что ни один из готовых инструментов не даёт мне:
- готового к работе API «из коробки»,
- с нормальной авторизацией (Basic/Bearer),
- с автоматической документацией (OpenAPI + Swagger UI),
- с возможностью легко менять схему данных без головной боли,
- и при этом без привязки к SDK — только универсальные протоколы (REST + WebSocket).
Все существующие решения либо запирают вас в своей экосистеме, либо заставляют писать/поддерживать код, либо дорожают как только проект выходит из песочницы.
Тогда я решил: а почему бы не сделать такое решение самому?
Хватит страдать. Так родился CastAPI — сервис, который сам хостит backend, позволяет визуально проектировать схему данных и сразу даёт готовый API без привязки к SDK.
🧩 Визуальный конструктор — никакого кода
Вместо того чтобы писать модели, миграции и контроллеры, вы просто рисуете структуру данных в браузере:
- Добавляете сущности (например, «Пользователь», «Заметка», «Тег»).
- Задаёте поля (текст, число, дата, булево, связи один-ко-многим, многие-ко-многим).
- Настраиваете правила доступа (кто может читать/писать).
Всё это — без единой строчки кода. Сервер сам создаст таблицы в PostgreSQL, настроит индексы и внешние ключи.
🔌 Универсальные протоколы — никаких SDK
Это ключевой принцип CastAPI. Вы не устанавливаете наш SDK — вы просто стучитесь по HTTP или подключаетесь по WebSocket. Работает из чего угодно:
- REST API — все стандартные эндпоинты генерируются автоматически: GET /posts, POST /posts, PATCH /posts/:id, DELETE /posts/:id, фильтрация, пагинация, сортировка. Тело запроса и ответа — чистый JSON.
- WebSocket — поддерживается из коробки по стандарту RFC 6455. Подписываетесь на изменения любой сущности и получаете realtime-события без дополнительных серверов.
- Telegram Bot API — вы просто создаёте блок «Telegram Webhook» в визуальном редакторе, указываете токен бота и пишете логику (например, «на команду /start отправить приветствие»). Всё остальное (приём сообщений, ответы, клавиатуры) CastAPI берёт на себя.
Никакой привязки к языку или платформе. Хотите писать клиента на React — используйте fetch. Хотите написать бота на Python — requests. Хотите подключиться из Go, Swift, Rust или даже Bash-скрипта — пожалуйста.
📚 Автоматическая документация OpenAPI + Swagger UI
Спецификация OpenAPI доступна по адресу:/api/v1/project/open-api/{projectId}А интерактивный Swagger UI — по адресу:/panel/project/open-api-ui/{projectId}
Документация всегда актуальна — вы не тратите время на её поддержку.
🔐 Аутентификация и роли
Поддерживаются два типа:
- Basic — логин и пароль в заголовке Authorization: Basic base64(login:password).
- Bearer (JWT) — при выборе этого типа CastAPI автоматически создаёт эндпоинт для получения токена:POST /api/app/docs/auth?login=user1&psw=123В ответе приходит {"token": "eyJhbGci..."}.Далее этот токен передаётся в заголовке Authorization: Bearer <token>.Вы можете задать время жизни токена (по умолчанию 86400 секунд = 24 часа).
Для тонкой настройки доступа создаются роли, которые затем привязываются к HTTP‑запросам или WebSocket‑точкам (разрешённые/запрещённые роли).
⚙ Процессы — бизнес‑логика без кода
В CastAPI всё строится вокруг процессов. Доступны типы:
- HTTP запрос — привязан к HTTP‑методу (GET, POST, PUT, PATCH, DELETE) и пути. Может принимать входной объект (кроме GET/DELETE) и возвращать выходной (один объект или список).
- Запланированный процесс — запускается по расписанию в формате CRON.
- Свободный процесс — вызывается из другого процесса (асинхронно или синхронно).
- Событие WebSocket — срабатывает при получении сообщения через WebSocket.
- Событие БД — триггерится при сохранении, обновлении, получении или удалении записи.
- Событие Telegram бота — обрабатывает команды (/start, /help), нажатия inline‑кнопок, новые сообщения, добавление бота в чат и т.д.
🎯 Пример за 5 минут: API для заметок с пользователями
Теперь покажу на реальном примере, как создать боевой backend с авторизацией, связями, WebSocket и запланированной очисткой старых записей.
Шаг 1. Создаём объект БД User (поддержка аутентификации)
В визуальном редакторе добавляем объект БД с именем User. Поля:
- address (тип STRING, необязательное)
- name (тип STRING, обязательное)
Отмечаем флаг «Поддержка аутентификации» — система автоматически добавит поля login, psw, roles.
Шаг 2. Выбираем шаблоны HTTP-запросов для User
При создании объекта БД CastAPI предлагает выбрать готовые шаблоны процессов:
- ✅ Создание записи → POST /user
- ✅ Получение записи по идентификатору → GET /user/:id
- ✅ Получение списка записей (макс. 200 на запрос) → GET /user
- ✅ Обновление записи → PATCH /user/:id
- ✅ Удаление записи по идентификатору → DELETE /user/:id
- ❌ Запланированный процесс (не нужен)
- ❌ Удаление старых записей (не нужно для пользователей)
Нажимаем «Сохранить» — все выбранные эндпоинты готовы к работе.
Шаг 3. Включаем аутентификацию Bearer (JWT)
В настройках проекта выбираем тип аутентификации Bearer и связываем его с объектом User. CastAPI автоматически создаёт эндпоинт для получения токена:POST /api/app/{projectName}/auth?login=...&psw=...
В ответ приходит JWT. Теперь к защищённым эндпоинтам нужно добавлять заголовок:
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Также можно настроить время жизни токена (по умолчанию 24 часа).
Шаг 4. Создаём объект БД Note со связью к User
Добавляем объект БД Note с полями:
- title (STRING, обязательное)
- content (STRING)
- userId (тип OBJECT_IDENTIFIER, включаем опцию «Связать с объектом БД» → выбираем User)
CastAPI автоматически создаст внешний ключ (FOREIGN KEY) в PostgreSQL, обеспечивающий ссылочную целостность.
Шаг 5. Выбираем шаблоны для Note
Отмечаем нужные шаблоны:
- ✅ Создание записи
- ✅ Получение по ID
- ✅ Получение списка (макс. 200)
- ✅ Обновление записи
- ✅ Удаление по ID
- ✅ Запланированный процесс — например, архивация заметок раз в сутки
- ✅ Удаление старых записей (макс. 200 за выполнение) — удалять заметки старше 30 дней
После сохранения все эндпоинты для Note готовы. Дополнительно настраиваем правила доступа через роли: например, разрешить создавать заметки только авторизованным пользователям, а изменять/удалять — только автору заметки. Это делается в интерфейсе без кода.
Шаг 6. Получаем готовый API
CastAPI уже сделал:
- БД PostgreSQL с таблицами user, note, настроены индексы и внешние ключи.
- HTTP-эндпоинты. Примеры:
- Автоматически работает запланированный процесс (CRON): каждую ночь запускается «Удаление старых записей» — чистит заметки старше 30 дней, максимум 200 за раз.
- Готова OpenAPI‑документация и Swagger UI для тестирования.
- При желании включаем WebSocket — клиенты подключаются по адресу:/ws/app/{projectName}/notes?projectToken=...&accountToken=...и получают realtime‑события о создании/обновлении/удалении заметок.
Всё это работает по чистому HTTP + JSON + WebSocket. Никаких SDK. Любой язык и любой HTTP‑клиент (fetch, axios, cURL, requests) подойдёт.
PS: Вот что вышло по примеру) https://lama-notes.ru. Да-да Lama работает на CastAPI
📌 Что дальше?
Сейчас CastAPI — в бета‑тестировании. Вы можете зарегистрироваться, создавать проекты, создавать HTTP запросы, открывать WebSocket-тунели и тд... И да.. Это все вообще бесплатно))) Только обязательно после регистрации нужно подтвердить email.
Я ищу первых пользователей, которые помогут обкатать сервис и добавят нужные фичи. Пишите в комментариях — отвечу на любые вопросы.