Чем ToolJet реально отличается от Appsmith — и это не список коннекторов

MAATRIX

Если открыть страницы интеграций ToolJet и Appsmith рядом, разницы почти не видно: PostgreSQL, MySQL, MongoDB, REST, GraphQL, Stripe, Slack, Google Sheets, Airtable, S3 — списки коннекторов совпадают процентов на восемьдесят. По этому критерию выбор не сделать, и большинство сравнительных статей на этом останавливаются. На практике же после установки на свой сервер и месяца работы разница вылезает совсем в другом месте: как устроен рантайм исполнения запросов, что происходит с формами и логикой сложнее «одна таблица — одна кнопка», и как оба инструмента ведут себя, когда пользователей и таблиц становится не два, а двадцать.

Список коннекторов одинаковый — архитектура нет

Оба продукта — open source low-code платформы для внутренних инструментов: панели администратора, дашборды поддержки, инструменты операционного отдела, которые обычно неделю заказывают у фронтенд-разработчика, а тут собирают за день. Но под капотом это разные стеки, и от этого зависит, сколько ресурсов закладывать на VPS и как сервис ведёт себя под нагрузкой.

ToolJet — это Node.js/NestJS-бэкенд плюс React-клиент плюс одна PostgreSQL, которая хранит и метаданные приложений (пользователи, права, определения страниц), и, при желании, данные самого встроенного хранилища ToolJet Database. Один язык на бэкенде, одна СУБД, относительно компактный набор процессов.

Appsmith — это Java/Spring Boot-сервер, встроенная MongoDB для метаданных приложений, Redis для кеша и сессий, отдельный Node.js-процесс RTS для совместного редактирования в реальном времени, и nginx поверх всего этого — всё в одном официальном контейнере. Подробный разбор этого стека и того, сколько памяти он реально ест, есть в статье сколько RAM нужно для Appsmith: там же видно, что JVM-сервер сам по себе занимает 400-900 МБ в простое, а MongoDB — ещё 150-300 МБ, и это без единого открытого приложения.

Практический вывод: на одинаковом VPS ToolJet стартует и работает при заметно меньшем базовом расходе памяти — он не тащит JVM и вторую СУБД в довесок к основной. Appsmith же с первой минуты требует держать в голове четыре разных процесса вместо одного-двух, у каждого свой профиль потребления памяти и свои логи для диагностики.

Цифры в таблице — ориентир по практике, а не результат контролируемого бенчмарка: точное потребление зависит от числа приложений, датасорсов и версий обоих продуктов на момент установки.

Где реально выполняются запросы и JS-логика

Это разница, которую не увидеть на скриншотах маркетингового сайта, но которая напрямую влияет на то, что тормозит — ваш сервер или браузер пользователя.

В ToolJet запросы к датасорсам и JS-трансформации данных по умолчанию выполняются на стороне сервера — нагрузка от тяжёлого запроса или сложной трансформации ложится на ваш VPS. Это предсказуемо и одинаково для всех пользователей независимо от мощности их ноутбука, но означает, что при росте числа одновременных пользователей сервер становится узким местом первым — не сеть, не браузер, а CPU процесса ToolJet.

В Appsmith часть логики — JS Objects, которыми обычно оформляют трансформацию данных для виджетов, — выполняется в браузере пользователя, а не на сервере. Запросы к датасорсам (SQL, REST, GraphQL) при этом всё равно идут через сервер. Это даёт более мягкое масштабирование по пользователям (тяжёлая клиентская логика не грузит ваш VPS), но и менее предсказуемое поведение: на слабом рабочем ноутбуке сложные JS-трансформации могут тормозить именно у конечного пользователя, и в серверных логах или docker stats вы этого не увидите — только в DevTools браузера того, кто жалуется.

Разница особенно заметна на сложных дашбордах, где виджет трансформирует тысячи строк перед отрисовкой: в ToolJet это добавляет нагрузку на ваш сервер (стоит следить за CPU процесса при тяжёлых вычисляемых полях), в Appsmith — на клиент, и сервер при этом выглядит спокойным, хотя жалобы на «тормозит» всё равно приходят.

Ни один из вариантов не лучше универсально — это компромисс между предсказуемостью (ToolJet, всё на вашем железе) и распределённой нагрузкой (Appsmith, часть работы уезжает к пользователю). Если у команды разномастные по мощности рабочие машины и много клиентской логики — это стоит учитывать при выборе.

Опыт сборки форм и сложной логики: где меньше трения

Базовый набор виджетов (таблица, форма, кнопка, селект, чарт, модалка) у обоих продуктов закрывает типовые задачи одинаково — тут выбирать особо не из чего. Разница всплывает на форме сложнее, чем «пять полей и кнопка сохранить».

Автогенерация форм из схемы. У ToolJet есть компонент формы, который умеет собирать поля на основе JSON Schema или структуры подключённой таблицы — удобно, когда таблица меняется и не хочется руками пересобирать каждое поле при добавлении столбца. У Appsmith подобный JSON Schema Form widget тоже есть, но по опыту самостоятельной сборки он менее гибко ведёт себя с вложенными объектами и массивами — приходится либо упрощать структуру данных перед формой, либо собирать часть полей вручную поверх auto-generated части.

Обработчики событий и цепочки действий. В обоих есть event handlers (на клик, на успешный запрос, на изменение значения) и цепочки из нескольких действий на одно событие. У ToolJet порядок и условия выполнения действий читаются чуть более линейно — легче восстановить логику через полгода, когда уже забыли, зачем добавили третий шаг. У Appsmith та же цепочка не хуже технически, но при большом числе условных переходов интерфейс требует больше скролла и переключений между вкладками, особенно если логика написана в отдельном JS Object, а не как встроенное действие компонента.

Отладка. У обоих есть встроенная консоль ошибок запросов и логи выполнения, но готового трейсинга «что именно упало и на каком шаге» цепочки действий из коробки нет ни там, ни там — это общее ограничение класса low-code инструментов, а не недостаток конкретно одного из них.

Здесь честно нет однозначного победителя: оба требуют привыкания, и разработчик, который два года собирал приложения в Appsmith, первую неделю в ToolJet будет чувствовать себя менее уверенно просто по инерции, и наоборот. Разница ощутима на реально сложных формах (вложенные условия, динамическое число полей, кросс-валидация между виджетами) — там ToolJet субъективно требует меньше обходных путей через кастомный JS, но это наблюдение из практики, а не измеримый факт.

ToolJet Database против «принесите свою БД»

Вот пункт, которого нет в списке коннекторов, но который меняет то, как вы вообще проектируете внутренний инструмент.

У ToolJet есть встроенная фича ToolJet Database — таблицы, которые можно создавать прямо в интерфейсе билдера без подключения внешней БД; физически они хранятся в той же PostgreSQL, что использует сам ToolJet для метаданных (или в отдельно указанной БД). Удобно для небольших внутренних инструментов, где не хочется поднимать отдельную БД ради одной таблицы с заявками.

У Appsmith аналогичной фичи для хранения пользовательских данных нет — он хранит только определения самих приложений (страницы, виджеты, права) в своей MongoDB, а данные вы обязаны брать из внешнего источника: PostgreSQL, MySQL, MongoDB, Google Sheets. Это чуть больше подготовительной работы на старте, но зато нет соблазна «пусть данные полежат внутри инструмента» — они изначально живут отдельно, и бэкап устроен так же, как для любой обычной БД.

Практический риск ToolJet Database: это встроенное удобство, а не полноценная замена спроектированной БД. Если через полгода такая «временная» таблица превращается в основной источник данных отдела продаж на несколько тысяч строк с ежедневной записью, вы обнаруживаете, что:

• она физически делит ресурсы той же PostgreSQL, что обслуживает саму платформу ToolJet — тяжёлая нагрузка на данные конкурирует с нагрузкой на метаданные приложений;
• бэкапить её нужно отдельно от привычного дампа «основной рабочей БД компании», и об этом легко забыть, потому что визуально это просто ещё одна таблица в билдере;
• индексы и оптимизация запросов там устроены проще, чем в вашей продуктовой БД, спроектированной под конкретную нагрузку.

Если вы понимаете это ограничение сразу и используете ToolJet Database только для действительно небольших вспомогательных данных (справочники, конфиги, короткие списки) — это чистый выигрыш по скорости старта. Если же таблица незаметно вырастает в критичный источник данных, её стоит вынести во внешнюю БД так же, как любой другой сервис — про диагностику подключения после такого переноса есть отдельный разбор: PostgreSQL не принимает подключения.

Что происходит при росте: больше пользователей, больше таблиц

Список коннекторов не расскажет, что случится с интерфейсом и сервером, когда вместо трёх пользователей и пяти приложений появится тридцать пользователей и полсотни приложений с общими датасорсами. Здесь у обоих продуктов есть свои узкие места, и оба стоит знать заранее, а не выяснять на проде.

Рост числа одновременных пользователей. У Appsmith совместное редактирование в реальном времени через RTS — заметная сильная сторона: несколько разработчиков видят правки друг друга онлайн, как в Google Docs. Но это же значит, что при росте числа одновременных сессий редактирования RTS-процесс держит больше открытых сокетов и требует больше памяти — закладывайте это отдельно от нагрузки на сам сервер и БД. У ToolJet real-time редактирование либо отсутствует, либо ограничено в зависимости от версии: меньше нагрузки на инфраструктуру, но выше риск конфликтов, если два человека одновременно правят одно приложение и последнее сохранение перезаписывает чужие правки.

Рост числа таблиц и датасорсов. Оба инструмента одинаково упираются в то, что widget-таблица без пагинации на уровне запроса тормозит на тысячах строк — это ограничение самой идеи «таблица в браузере», а не конкретной реализации. Разница в том, где вы это почувствуете первым: в ToolJet — на сервере, в Appsmith — чаще в браузере, если тяжесть в JS-трансформации, и на сервере, если тяжесть в самом SQL-запросе.

Рост числа приложений и прав доступа. С ростом количества внутренних инструментов на одном инстансе управление правами требует дисциплины у обоих — оба поддерживают роли на уровне workspace, но детальные права стоит проектировать заранее, а не добавлять по факту, когда пользователей уже тридцать и в правах никто не может разобраться.

Если ожидается рост команды разработчиков внутренних инструментов (не пользователей приложений, а людей, которые их собирают) — совместное редактирование Appsmith становится реальным преимуществом. Если один-два человека собирают инструменты, а растёт число конечных пользователей и объём данных — компактный стек ToolJet проще держать под контролем на среднем VPS.

Установка и эксплуатация на своём сервере

Оба разворачиваются через Docker за 15-20 минут, но профиль эксплуатации после установки заметно отличается.

Минимальный docker-compose.yml для ToolJet (сокращённо, без TLS-терминации — её лучше вынести на отдельный reverse proxy):

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: tooljet
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_DB: tooljet_production
    volumes:
      - pg_data:/var/lib/postgresql/data

  tooljet:
    image: tooljet/tooljet-ce
    restart: unless-stopped
    depends_on:
      - postgres
    ports:
      - "8082:80"
    environment:
      PG_HOST: postgres
      PG_DB: tooljet_production
      PG_USER: tooljet
      PG_PASS: ${DB_PASSWORD}
      SECRET_KEY_BASE: ${SECRET_KEY_BASE}
      LOCKBOX_MASTER_KEY: ${LOCKBOX_MASTER_KEY}
      TOOLJET_HOST: https://tooljet.example.com
    volumes:
      - tooljet_data:/app/storage

volumes:
  pg_data:
  tooljet_data:

SECRET_KEY_BASE и LOCKBOX_MASTER_KEY генерируются один раз при установке и обязаны сохраняться неизменными между перезапусками и обновлениями — потеряете их, и расшифровать сохранённые креды датасорсов не получится, точно так же, как с ключом шифрования у Appsmith. Держите .env в бэкапе так же аккуратно, как сам том с данными.

У Appsmith установка проще на старте (один контейнер вместо двух сервисов), но диагностика при сбоях требует смотреть логи сразу нескольких внутренних процессов — конкретные сценарии падений, конфликтов портов и обрыва подключения к внешней БД разобраны в статье Appsmith на сервере: частые ошибки и решения, и часть из них (нехватка памяти, файрвол, reverse proxy) актуальна для любого self-hosted low-code инструмента, включая ToolJet.

Общие правила эксплуатации, которые не зависят от выбора платформы:

• бэкапьте том с данными и .env вместе, одним снапшотом — раздельные бэкапы почти гарантированно рассинхронизируются рано или поздно;
• перед обновлением версии делайте бэкап тома, а не надейтесь на откат образа — миграции схемы БД не всегда обратимы;
• держите оба сервиса за reverse proxy с TLS-терминацией на уровне Nginx/Caddy, а не внутри приложения. Общий чек-лист по типовым граблям self-hosted compose-стека — в статье про production-конфигурацию Docker Compose.

Частые вопросы