«Кубики» вместо кода — год спустя

Ровно год назад мы опубликовали пост на трибуне, в котором рассказали историю low-code платформы Directual. Сегодня я поделюсь тем, что мы узнали на практике за год, и куда мы дальше двигаемся. Спойлер: кровавый энтерпрайз ушел на второй (и даже третий) план, а облачная версия платформы — на первый.

«Кубики» вместо кода — год спустя

Что такое low-code?

Это подход, когда ИТ-продукты можно разрабатывать в визуальном интерфейсе. Также для этого в ходу близкие термины no-code или zero-code. Идея «накидывать приложение мышкой» появилась давно, но только в последнее годы такие продукты стали использоваться массово. Например, сейчас никто не кодит лендинги — их собирают на Tilda или Readymag. Даже наш текущий сайт на 100% сделан только дизайнером на no-code платформе Webflow. Предпосылки для такого подхода очевидны: программисты дорогие, плюс гибкость становится решающим фактором. Подвигать элементы мышкой и задеплоить по кнопке — это 5 минут. Писать ТЗ, ставить задачу и тестить — это дни, в лучшем случае.

Я бы выделил три группы low-code платформ:

  • для интерфейса (уже упомянутые Webflow, Tilda, Readymag и еще немало);
  • для интеграций (тут приходит на ум Zapier и IFTTT);
  • для бэкенда: базы данных, авторизации пользователей, какой-то логики и т. д.

Мы как раз сделали фокус на последнем пункте. Исторически, в нем меньше всего конкурентов, и он самый «программистский». Например, Firebase от Google можно частично отнести сюда. Или более простой Airtable. Причин неразвитости этого сегмента несколько. В том числе — стереотип, что на конструкторах можно сделать поделку на коленке, а для нормального решения надо нанимать программистов. Мы в Directual на своем примере доказали, что на современных low-code решениях можно делать как MVP стартапа, так и промышленные системы.

Смена фокуса в 2019

Начинали 2019 мы так:

  • Крупные заказчики, для которых наша же команда делала на платформе проекты: ПИК, МТС. Для примера, среди решений были: внутрення база знаний (замена Confluence, в котором не хватало системы согласования), конструктор договоров, оптимизация логистики панелевозов.
  • Пайплайн разработки строился, в первую очередь, под нужны консалтинг-офиса. Иногда в жертву функциональности приносилось удобство и продуманность фичи.
  • Стратегия «заработать денег на крупняке», а потом уже инвестировать в публичное облако для широкого рынка.

Что из этого вышло — далее.

Цикл продажи в крупную компанию — год. Минимум. За этот год надо выстроить отношения, сделать бесплатный пилот (для которого, возможно, нужны доработки в платформу), договориться с безопасниками и айтишниками об установке в контур. И под это нужен штат: продажники, инженеры, менеджеры. Собственно, половина консалтинг-команды трудилась на разных пресейлах.

Инсталляция On-Premise решения, которое создано на сложной модульной платформе — это отдельная история. У многих заказчиков нет нормальных девопсов, которые могли бы эксплуатировать платформу. И на пилот в контуре серверы выделяются очень экономно. В итоге, многие ключевые инженеры занимались тем, что поднимали платформу в разных контурах заказчиков, в том числе без доступа к интернету.

Мы встали перед выбором: либо окончательно уходить в корпоративные «продажи печенью» и становиться еще одним системным интегратором (пусть даже модным, на собственной платформе), либо вспомнить, что нас вдохновило на создание этой компании, и запускать наконец-то наш продукт на широкий рынок.

В конце 2019 года мы решились на следующее:

  • Сокращаем всю команду внедрения. Часть устраиваем к клиентам. Часть — переводим на партнерские отношения.
  • Текущие проекты не бросаем, но делаем силами партнеров-студий.
  • На основе отзывов, которые мы получили от 300 облачных бета-пользователей, делаем новую версию платформы. И открываем с ней публичное облако.
  • К релизу готовим качественные учебные пособия.

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

Что можно сделать на Directual?

Вот наглядная картинка из нашей документации (её мы еще обновляем, немного не успевая за фичами):

«Кубики» вместо кода — год спустя

Что полностью разворачивается и настраивается на Directual:

  • База данных. Отлично масштабируется, можно делать импорт/экспорт в Excel, ставить слушатели на внешние SQL-базы. Тут же хранится и ролевая модель, и файлы, и логи приложения. Под капотом: MongoDB (для данных) и PostgreSQL (для метаданных).
  • Логика бэкенда. Наши сценарии (потоковая обработка данных) + отчеты (пакетная обработка). Из сценария можно постучаться во внешнюю систему через шаг http-запроса.
  • API и RBAC. По-сути — один модуль, исторически называется Security layer. Это конструктор API с кучей настроек: фильтры, сортировки, синхронные сценарии и т. д. Для Академии пришлось делать два отдельных урока по API-конструктору.
  • Портал Directual. Фича пока в альфе. Это то, что просили наши бета-тестеры. Не все готовы программировать свой фронтенд. Портал — это простой шаблон сайта, который поддерживает авторизацию. На страницы этого сайта можно накидывать компоненты, взаимодействующие с данными через API. Пока компонента три: текстовый блок, форма и отображение данных в виде карточек. Вот пример портала на Directual . Еще удобная функция: любую страницу можно вставлять как iframe к себе на сайт (в том числе собранному на конструкторах типа Webflow или Tilda).

Что не делается на Directual:

  • Тонкий клиент веб-приложения, для которого платформа работает как REST-интерфейс. Хотя, как я писал выше, можно вставлять embedded-элементы. Сам фронт можно делать хоть на чем: React, Angular, Vue, JQuery. Для ReactJS мы сделали и выложили в open source: библиотеку компонентов Directual.design и boilerplate для упрощения работы с платформой как бэкендом.
  • Мобильное приложение. Разрабатывается отдельно нативно или PWA, но может работать с теми же API-методами. Пример недавно запущенного iOS-приложения с бэком на Directual — Up&out (это что-то среднее между Tinder и Linkedin).

Для эффективного использования полезно знать основы проектирования баз данных и базу JavaScript (достаточно самого простого курса на той же Codecademy).

Предвосхищая вопрос: «Почему все на английском?», отвечу. Делать материалы на двух языках вдвое дольше. Поэтому мы пока выбрали один — международный.

Сколько стоит?

Бесплатный тариф позволяет делать все, но не нагружать платформу (по операциям процессинга — сценариям, и по запросам к API). Без ограничения по времени. Сколько надо, столько и эксперементируйте.

Тариф Startup. Дешево и сердито — $30 в месяц. С лимитами по нагрузке, которых вполне хватит на запуск MVP. Можно включить on-demand биллинг, тогда приложение не будет останавливаться при достижении лимитов, но будет сниматься дополнительная плата за превышение потребляемой мощности.

Business. За $300 вы получите в 20 раз выше лимиты, в 2,5 раза меньше цену за превышение. И SLA на 99% uptime. На таком тарифе у нас работают ребята из Schlumberger.

Что дальше?

Стратегически, наша задача следующая: дать простой и красивый инструмент для широкого рынка и вписаться в существующую экосистему low-code продуктов.

Тактически, будем делать упор на продвижение через контент-маркетинг, блог и полезные материалы формата «пошаговая инструкция как с помощью Directual и синей изоленты запилить стартап». Также хорошо видно, что развитии low-code продуктов большую роль играют сообщества пользователей. Присоединяйтесь к нашему — платформа уже открыта для регистрации!

В ближайших релизах мы планируем: добавить компонентов для портала, интеграцию с Zapier, новые кубики для сценариев. Вопросы и пожелания по фичам можно писать на форуме, или на почту hello@directual.com.

Также мы рады сотрудничать с веб-студиями. Обучим, поделимся лицензионными платежами, и даже клиентов можем подогнать.

3939
33 комментария

Я ботика могу запилить 😂

3
Ответить

За LCDP будущее, но для хорошей реализации надо быть гением.

2
Ответить

Будущее - вполне возможно, но это никак не облегчит боль конечного пользователя. Просто на рынке начнут конкурировать десятки и сотни LCDP сервисов, между которыми неизбежно потребуются интеграции, для которых потребуются сотни и тысячи дополнительных плагинов, для тонкой настройки которых потребуются миллионы программистов - и т.д. и т.п. по хорошо известному пути развития IT экосистем, который человечество проходило уже неоднократно на разных витках спирали.

2
Ответить

Это почти как SQL задумывался как язык для домохозяек. Домохозяйки на нем так и не пишут, но подход реализован необычный)

2
Ответить

Комментарий недоступен

1
Ответить

Баббл прекрасен для несложных решений. Постараемся написать сравнения лоу-код платформ в ближайшее время.

2
Ответить

В итоге, у вас получился конструктор БЭ. БД вы взяли готовый, ФЭ тоже взяли готовый. Продукт полюбому придется в сотнях маст допиливать, надстраивать и интегрировать. Очевидный вопрос - зачем? Какую проблему конечного потребителя вы решаете?

2
Ответить