Некоторые считают, что подход без кода ограничен и может использоваться только для MVP. Это не так! В этой короткой статье вы узнаете, почему иногда no-code не работает, а где — работает отлично.
Скажу честно, это распространённое опасение среди большинства начинающих no-code разработчиков или тех, кто рассматривает использование no-code решения. Это неудивительно: на большинстве no-code платформ обычно можно действительно хорошо делать что-то одно, а для масштабирования полагаться на что-то другое. Возможно ли это вообще в принципе?
Да.
Скажу вам прямо здесь и сейчас: no-code платформы можно использовать на любом этапе развития продукта, включая позднюю стадию. Просто нужно правильно выбрать платформу и сторонние системы (если они вам нужны). Конечно, потребуется некоторое ноу-хау и эксперименты, но не стоит делать поспешные выводы, пока вы не увидите полную картину того, что такое масштабируемость на самом деле.
«Масштабирование» в истинном смысле зависит от множества факторов:
Конечно, если вы когда-нибудь достигнете масштабов Twitter или Google, может потребоваться что-то более устойчивое, но это будет приятной проблемой.
Главное узкое место, с которым сталкиваются многие no-code платформы, — это скорость обмена данными, из-за чего некоторые из них могут казаться медлительными или обрабатывать запросы целую вечность. Тем не менее, чтобы это произошло, нужно достичь по-настоящему колоссального объёма транзакций.
Другое препятствие для масштабирования связано не с конструкторами приложений, а скорее с общим непониманием того, что такое no-code, и новизной всего этого. Платформы гонятся за постоянно меняющимся спросом и развивающимися технологиями, а мы, простые смертные, пытаемся успевать за ними и одновременно что-то строить.
Самый большой показатель масштабируемости no-code платформ — это... сами no-code платформы. Bubble, Zapier и даже наша собственная платформа во многом построены на своём собственном функционале.
Что действительно необходимо для масштабируемого, надёжного продукта, построенного на no-code платформе, — это знание правильного технологического стека и предварительное тестирование, прежде чем делать выводы.
Недавно вышел информативный пост от FINN, немецкого сервиса подписки на автомобили, который начал свой путь с помощью no-code платформы. FINN пережил взрывной рост, а вместе с ним, естественно, появился ряд проблем, которые оказались непосильными для их технологического стека на тот момент.
Когда я говорю «взрывной рост», я имею это в виду буквально: всего за один год они достигли 4 млн евро ARR и выросли с 0 до 20 000 подписок. Это немалое достижение, поэтому этот случай так интересно анализировать.
FINN использовал Airtable, Make и Retool среди прочих инструментов технологического стека для построения инфраструктуры, автоматизации и других вспомогательных систем. Естественно, это доказывает, что no-code инструменты были прекрасны для первого этапа развития их продукта. Конечно, проблемы не заставили себя ждать, как только рост стал по-настоящему взрывным, вот некоторые из них:
После того как эта проблема развернулась, и накануне выхода на рынок США, FINN приняла решение перейти на традиционное программирование и начать с нуля. Процесс миграции всё ещё продолжается, он займёт некоторое время, но при правильном подходе, конечно, в итоге всё будет хорошо.
Однако вся эта проблема возникла в первую очередь из-за неправильного стека инструментов. И вот небольшое доказательство этому.
Один из наших клиентов, Karma (глобальная платформа p2p-займов), идёт по пути, похожему на FINN: взрывной рост, сложный продукт, множество автоматизации и выход на новые рынки.
За исключением одного небольшого отличия: нет необходимости передавать всю инфраструктуру команде разработчиков, чтобы строить её с нуля, потому что она уже масштабируется достаточно хорошо. Но в чём же секрет?
Правильный технологический стек.
Путь Karma в некотором смысле был противоположным, когда дело касалось разработки: они начали с команды разработчиков, которой требовалось слишком много времени на подготовку необходимых систем, что было слишком дорого и намного менее гибко. Однако между этими двумя случаями есть общий элемент: Bubble! Но только для фронтенд-целей, потому что я не боюсь это сказать: фронтенд-шаблоны Bubble выглядят действительно великолепно.
Теперь Karma на пути к успеху, легко масштабируясь до любого предела, который им нужен, при этом мощные бэкенд-возможности Directual берут на себя всю тяжёлую работу. Сбои базы данных? Нет. Задержки синхронизации? Ничего подобного. Это просто работает!
Если в этот момент вы удивлённо приподняли брови — это нормально. Karma не является точной копией бизнес-модели или подхода FINN. Вывод здесь предельно прост: no-code/low-code платформы могут легко масштабироваться вместе с продуктом, если предварительно их проверить.
С правильным технологическим стеком и постоянным развитием no-code конструкторов приложений, это становится способом разработки новых продуктов, независимо от размера или нагрузки. Это быстрее, значительно дешевле и имеет гораздо более пологую кривую обучения. Движение no-code растёт до своих нынешних масштабов не просто так.
Лучший путь — сочетать лучшее из обоих миров: гибкость и скорость no-code с лучшими практиками разработки традиционного программирования. Вы можете добиться гораздо большего с меньшими затратами, если готовы пробовать новое.
Стремитесь к звёздам, имея в руках правильный технологический стек!
Если вы хотите узнать, как всё это работает на нашей платформе, напишите нам на hello@directual.com.
